# [RISOLTO] Conflitto e2fsprogs

## geps2

Ho questa situazione:

```

[ebuild  N    ] sys-libs/e2fsprogs-libs-1.41.2  USE="nls"

[ebuild   R   ] dev-libs/apr-1.3.2

[ebuild   R   ] dev-libs/xplc-0.3.13-r1

[ebuild   R   ] sys-fs/cryptsetup-1.0.5-r1

[ebuild  N    ] sys-fs/e2fsprogs-1.41.2  USE="nls"

[ebuild   R   ] dev-libs/apr-util-1.3.2

[ebuild     U ] app-crypt/mit-krb5-1.6.3-r4 [1.6.3-r1]

[ebuild   R   ] app-misc/mc-4.6.1-r4

[ebuild   R   ] dev-util/subversion-1.5.2

[ebuild   R   ] sys-apps/util-linux-2.13.1.1

[blocks B     ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.3)

[blocks B     ] sys-libs/e2fsprogs-libs (is blocking sys-libs/com_err-1.40.11)

```

Ho provato a unmergere com_err, ma questa è necessaria per emergere gli altri pacchetti!

Qualche suggerimento?Last edited by geps2 on Sun Nov 02, 2008 9:26 am; edited 2 times in total

----------

## lucapost

L'ho trovato anche io questo, si risolve con:

```
emerge -C com_err e2fsprogs 

emerge -uND world
```

alla fine com_err non è un pacchetto di sistema, quindi anche le lo rimuovi temporaneamente non cambia nulla...

----------

## djinnZ

Il suggerimento è altamente sconsigliabile. Se leggi qui capirai che stavolta i nostri beneamati devel l'hanno fatta proprio grossa (mi ero da poco lanciato in loro difesa in un thread lamentando lo scarso numero di bestemmie e sono stato subito accontentato).

Il problema è che e2fslibs sostituisce com_err ed ss ma le dipendenze di molti ebuild non sono state aggiornate (ed in qualche caso la dipendenza alternativa non è stata neanche lontamente verificata).

L'unica cosa che puoi fare ora è un emerge -t per vedere cosa richiede l'ultima versione di e2fsprogs o direttamente e2fslibs e mascherare.

L'unica soluzione alternativa seria è questa. Ma personalmente ho preferito attendere (solo mc e nfs-utils rompono e possono benissimo attendere il prossimo upgrade)

[OT] *Quote:*   

> [HELP] Dipendenza circolare!

 peccato solo... che questo non sia un helpdesk...   :Evil or Very Mad: 

 *Quote:*   

> dipendenze: e2fsprogs-libs blocca com_err ed ss

 ad esempio. Sono stato sinceramente tentato di non rispondere.

[/OT]

----------

## Peach

ho il terrore che questo thread finirà in sticky (e spero che quello con expat glib etc venga destickato... o no?)

----------

## bandreabis

il problema nasceva da mit-krb5.

Ora hanno messo a posto (credo, perchè ieri ho dovuto aggiornare questo pacchetto) con una nuova versione stabile.

----------

## cloc3

sul forum italiano, se ne era parlato qui.

forse è opportuno un merge, sopratutto se il problema dovesse creare disturbo nel tempo.

confermo che la soluzione indicata da djiinz è rapida ed efficace.

a me ha reso stabile il sistema da più di un mese.

non ci farei troppe imprecazioni.

----------

## djinnZ

 *Quote:*   

> Inviato: 20.59 Mercoledì 17 Settembre 2008

 ci stanno tutte le bestemmie...  :Twisted Evil:  anche quelle in sanscrito.

Il problema è un tantino differente adesso perchè all'epoca e2fslibs era opzionale e non necessario a pacchetti di uso comune come nfs o e2fsutils. Il problema è che qualche genio ha chiuso il bug visto che il problema su mit-krb5 era risolto e non erano state aggiornate le dipendenze alternative.

Resto dell'idea che per il momento è meglio attendere che rimettano a posto le dipendenze tanto non è che gli aggiornamenti siano legati a vulnerabilità o problemi gravi.

Non capisco perchè i devel non abbiano semplicemente mascherato di nuovo i pacchetti che creano il problema.

----------

## SbiellONE

anche io ho avuto questo problema ed ho deciso di adottare la soluzione proposta ed ha funzionato

cosa dovrò fare una volta che gli sviluppatori avranno risolto il problema?

----------

## cloc3

 *SbiellONE wrote:*   

> anche io ho avuto questo problema ed ho deciso di adottare la soluzione proposta ed ha funzionato
> 
> cosa dovrò fare una volta che gli sviluppatori avranno risolto il problema?

 

anche nulla.

potrebbe essere utile rimuovere i contenuti aggiunti in /etc/portage per evitare di mantenere pacchetti superflui in ~ e per non appesantire inutilmente il lavoro di emerge.

----------

## bandreabis

 *SbiellONE wrote:*   

> anche io ho avuto questo problema ed ho deciso di adottare la soluzione proposta ed ha funzionato
> 
> cosa dovrò fare una volta che gli sviluppatori avranno risolto il problema?

 

Risolto.

----------

## djinnZ

 :Question:   :Shocked:   :Question: 

----------

## bandreabis

 *djinnZ wrote:*   

>   

 Forse ora si capisce il senso...   :Very Happy: 

 *SbiellONE wrote:*   

> anche io ho avuto questo problema ed ho deciso di adottare la soluzione proposta ed ha funzionato
> 
> cosa dovrò fare una volta che gli sviluppatori avranno risolto il problema?

 

Risolto.

----------

## geps2

Ok, ho capito, ma adesso ho un problema più grosso: al boot non mi monta più root!

Perché ho cercato di togliere un po' di roba prima di scrivere il post, e mi sa che togliendo qua e togliendo là ho tolto qualcosa di fondamentale: adesso al boot ho questo: 

```
* Mounting proc at /proc ... [oops]

The "mount" command failed with error:

error while loading libblkid.so.1: cannot open shared object file: No such file or directory

* Since this is a critical task, startup cannot continue.

Give root password for maintenance

(or type Control-D to continue):
```

Che faccio adesso? Posso recuperare oppure mi tocca reinstallare (non vorrei farlo!)?

Mi viene in mente di andare a copiare un file libblkid.so.1 sotto /usr/lib o qualche altro path: potrebbe funzionare? Dove lo prendo eventualmente il file?

Vi prego aiutatemi!!!

----------

## cloc3

 *geps2 wrote:*   

> *

 

 :Smile: 

ecco. se avessi letto il topic che avevo postato, ti saresti fatto un backup dei pacchetti precedenti prima di cominciare l'upgrade...

comunque, niente paura. la tua idea, di rimpiazzare libblkid.so.1 in qualche posto è corretta, ma ovviamente devi usare la libreria vera, non un file qualunque. nel mio sistema, le cose stanno così:

```

cloc3@s939 ~ $ su -

Password: 

s939 ~ # ldd /bin/mount

   linux-vdso.so.1 =>  (0x00007fff3a7fe000)

   libblkid.so.1 => /lib/libblkid.so.1 (0x00007fdb32325000)

   libc.so.6 => /lib/libc.so.6 (0x00007fdb31fdd000)

   libuuid.so.1 => /lib/libuuid.so.1 (0x00007fdb31dd8000)

   /lib64/ld-linux-x86-64.so.2 (0x00007fdb32531000)

s939 ~ # qfile libblkid.so.1

app-emulation/emul-linux-x86-baselibs (/lib32/libblkid.so.1)

sys-libs/e2fsprogs-libs (/lib64/libblkid.so.1)

```

ovviamente tu non posisedi ancora il pacchetto sys-libs/e2fsprogs-libs, ma può essere che tu abbia in /usr/portage/packages uno di questi:

sys-libs/com_err

sys-libs/ss

e2fsprogs - versione vecchia   :Idea: 

reinstallando con emerge -K quello dei due che contiene la libreria richiesta, dovresti riprendere il sistema.

magari lavora in chroot partendo da un cdrom o da una chiavetta autonoma.

se non possiedi i pacchetti pronti utilizza la libreria del cdrom. questo modo è leggeremente più sporco, perché la presenza dei file non sarà registrata nei database di sistema, ma non è proprio il caso di fare queste sottigliezze.

p.s. nessuna paura. con la calma dovuta, da questi pasticci si esce sempre.

----------

## silvius

Anch' io ho eliminato le lib necessarie per il mount infatti:

```
(chroot) ldd /bin/mount

        linux-gate.so.1 =>  (0xffffe000)

        libblkid.so.1 => not found

        libuuid.so.1 => not found

        libc.so.6 => /lib/libc.so.6 (0xb7e52000)

        /lib/ld-linux.so.2 (0xb7f9c000)
```

ho provato con un :

emerge --oneshot sys-libs/ss sys-libs/com_err

ma non va ugualmente, anceh se l' emerge va a buon fine.

Ho provato ad usare l' emerge -K, ma non so quale pacchetti dargli.

Nelle man viene detto che usa i pacchetti linkati dalla variabile $pkgdir.....ma non c'è nulla in quella posizione.

Cosa posso fare ?

Saluto

----------

## cloc3

 *silvius wrote:*   

> 
> 
> Ho provato ad usare l' emerge -K, ma non so quale pacchetti dargli.
> 
> 

 

purtroppo non posso risponderti con assoluta sicurezza perché, avendo già fatto l'upgrade, la mia situazione attuale è diversa dalla tua.

ma, guggolando in giro, mi sono fatto l'idea che la tua libreria appartenga al pacchetto e2fsprogs - versione vecchia (anzichè e2fsprogs-libs).

prova ad emergere quello.

oppure taglia la testa al toro prendendo le librerie da un qualunque cdrom.

in fondo, appena avrai completato l'upgrade, quel pacchetto sarà ricompilato in automatico.

e in ogni caso, un revdep-rebuild supplettivo dovrebbe essere sufficiente a verificare la consistenza globale del sistema.

----------

## silvius

Proverò prendendo lib da un cd....prendo le lib e le inserisco dentro /lib/....

Per emerge -K sai che pacchetti dovrei dargli in pasto ? tanto per capire....perchè nelle man mi dice di prendere i pacchetti in /usr/portage/package....ma non esiste neanche questa cartella.

Saluto

----------

## geps2

 *djinnZ wrote:*   

> 
> 
> [OT] *Quote:*   [HELP] Dipendenza circolare! peccato solo... che questo non sia un helpdesk...  
> 
>  *Quote:*   dipendenze: e2fsprogs-libs blocca com_err ed ss ad esempio. Sono stato sinceramente tentato di non rispondere.
> ...

 

Grazie per i suggerimenti.

[OT] Forse non ho cercato abbastanza...[/OT]

----------

## djinnZ

te lo chiedo gentilmente (si fa per dire  :Twisted Evil:  ): CAMBIA IL TITOLO IN QUALCOSA DI COMPRENSIBILE!

[OT]ma i moderatori stanno ancora a smaltire i postumi (della sbronza) del sabba di ieri sera?  :Laughing:  O sono tutti alle prese con pannolini e pappine?  :Laughing:  [/OT]

@bandreabis: alle volte ( quasi sempre  :Twisted Evil:  ) faccio estrema fatica a comprendere quello che scrivi. Il problema è tutt'altro che risolto e, qualora volesse essere un improbabile tentativo di fare dell'umorismo... non lo capisco, sarà l'artereosclerosi, ma non lo capisco.

----------

## bandreabis

 *djinnZ wrote:*   

> @bandreabis: alle volte ( quasi sempre  ) faccio estrema fatica a comprendere quello che scrivi. Il problema è tutt'altro che risolto e, qualora volesse essere un improbabile tentativo di fare dell'umorismo... non lo capisco, sarà l'artereosclerosi, ma non lo capisco.

 

Esagerato. A me pare di scrivere in italiano  ( quasi sempre  :Twisted Evil:  ).

In ogni caso pare che il problema fosse dovuto al pacchetto mit-krb5 che bloccava tutto in base di sue dipendente non perfette.

Aggiornato quel file ad una versione mascherata il blocco spariva.

Ora (beh, quando avevo scritto il messaggio sotto riportato) hanno smascherato e messo stabile una versione che non da più i problemi della versione rimpiscatole.

Spiero di essermi spiegato in modo sufficiente.

 *bandreabis wrote:*   

> il problema nasceva da mit-krb5.
> 
> Ora hanno messo a posto (credo, perchè ieri ho dovuto aggiornare questo pacchetto) con una nuova versione stabile.

 

PS: volevi scrivere arteriosclerosi?

----------

## djinnZ

da quello che ho capito invece per causa dei problemi di dipendenza di mit-krb5 non sono state riviste le dipendenze in modo tale da poter accettare il passaggio ad ext2libs o come diavolo si chiama.

Nel frattempo mit-krb5 è stato considerato a posto mentre non lo era

Nfs-utils, base-utils, mc e non ricordo quanti altri pacchetti continuano ad avere problemi di dipendenza perchè chiedono com_err ed ss che sono stati assorbiti da ext2libs.

Da quel che ho letto sui forum questi pacchetti non hanno problemi ad essere compilati ed eseguiti con il nuovo assetto delle librerie ma gli ebuild continuano a richiedere com_err ed ss (per questo la soluzione di usare package.provided). Nel dubbio, se devi lavorarci, è meglio non aggiornare per niente.

La questione è tutt'altro che risolta, quel che non capisco è perchè i devel non hanno semplicemente riportato indietro l'abero di portage

----------

## silvius

 *silvius wrote:*   

> Proverò prendendo lib da un cd....prendo le lib e le inserisco dentro /lib/....
> 
> Per emerge -K sai che pacchetti dovrei dargli in pasto ? tanto per capire....perchè nelle man mi dice di prendere i pacchetti in /usr/portage/package....ma non esiste neanche questa cartella.
> 
> Saluto

 

Con le lib sono a posto, ma al boot si blocca perchè non trova il comando fsck......vorrei entrare in chroot ed emergere il paccheto che contiene il fsck.....qual'è il pacchetto ?

Saluto

----------

## silvius

qualche pacchetto oltre e2fsprogs.....

In chroot non mi funzionano i package.mask e unmask.....perchè ?

Saluto

----------

## silvius

OK....ci sono la mia gentoo è su !!!!!

Grazie dei consigli

Saluto

----------

## lucapost

Caspita che polverone che è stato sollevato.

Resta il fatto che, anche se non consigliato, io ho risolto come ho indicato nella seconda risposta del thread, e non riscontro alcun problema. 

Sarà stata solo fortuna....

----------

## geps2

 *djinnZ wrote:*   

> te lo chiedo gentilmente (si fa per dire  ): CAMBIA IL TITOLO IN QUALCOSA DI COMPRENSIBILE!

 

Va bene va bene! Se non va bene nemmeno quello che ho messo accetto suggerimenti  :Wink: 

----------

## cloc3

 *lucapost wrote:*   

> 
> 
> Sarà stata solo fortuna....

 

anche fortuna.

gentoo è una metadistribuzione proprio perché emerge non si comporta con tutti allo stesso modo.

il guaio è che se sbagli e non hai abbastanza esperienza, ti ritrovi il comando mount fuori uso e la partizione usr appiedata all'avvio successivo.

... che non è una condizione carina per un nuovo arrivato.

probabilmente, i moderatori avrebbero dovuto cambiarlo loro il titolo, fare il merge con il post precedente e segnalare la discussione nello sticky degli upgrade (che tra l'altro abbisogna di una spolveratina).

se non l'hanno fatto, temo che anche per loro siamo in un momento di stanca.

----------

## djinnZ

Si vede che non usi ext2/3 come filesystem. Ripeto che mascherare gli aggiornamenti è solo precauzione, sul server potrei visto che il supporto ad extfs non c'è neppure nel kernel.

Secondo i casi vedi quale delle tre possibilità ti torna più comoda, tanto per cambiare.

----------

## lucapost

 *djinnZ wrote:*   

> Si vede che non usi ext2/3 come filesystem.

 

Ti riferivi a me? Comunque la partizione dati è ext3: 

```
/dev/hdc4     ext3    52821912  20827668  29310988  42% /mnt/data
```

e dopo aver rimosso i tre pacchetti che creavano il conflitto, aggiornao il world, ripeto nessun problema. Anche se, non ricordo bene, ma forse mi è scappato un revdep-rebuild dopo l'aggiornamento (lo lancio dopo ogni update).

----------

## lordalbert

 *bandreabis wrote:*   

>  *SbiellONE wrote:*   anche io ho avuto questo problema ed ho deciso di adottare la soluzione proposta ed ha funzionato
> 
> cosa dovrò fare una volta che gli sviluppatori avranno risolto il problema? 
> 
> Risolto.

 

a me il problema (amd64) si presenta ancora...

----------

## bandreabis

non so su amd64, scusa.

Mi riferivo a x86. Io ho aggiornato mit-krb5 a 1.6.3-r4 e il problema si è risolto.

----------

## .:deadhead:.

Io ho dovuto ricompilare util-linux per aggiustare il comando mount: quasi per caso l'ho lanciato dopo aver rimosso ext2-libs e non andava nulla. un ldd ha svelato l'arcano.

----------

## Deus Ex

 *lordalbert wrote:*   

>  *bandreabis wrote:*    *SbiellONE wrote:*   anche io ho avuto questo problema ed ho deciso di adottare la soluzione proposta ed ha funzionato
> 
> cosa dovrò fare una volta che gli sviluppatori avranno risolto il problema? 
> 
> Risolto. 
> ...

 

Idem come sopra

----------

## thefantaman

non eseguite ASSOLUTAMENTE

emerge -C com_err e2fsprogs

emerge -uND world

come consigliato all'inizio. Perchè? Altrimenti mi fate compagnia e gentoo non parte più.......  :Mad: 

----------

## falko

 *thefantaman wrote:*   

> 
> 
> non eseguite ASSOLUTAMENTE
> 
> emerge -C com_err e2fsprogs
> ...

 

Io ho fatto esattamente cosi anzi:

emerge -C com_err e2fsprogs e2fsprogs-libs

emerge -uND world

e logicamnete, prima wget si è incaz. di brutto dicendomi che non trovava la libreria condivisa

libcom_err.so.2. Cosi mi sono detto genero la lista dei file che mi servono, li scarico da un altro

PC e poi emergo (logicamente senza riavviare!!! non sono mica C.); beee ennesima cazz. perchè non riesco più a montare la chiavetta usb; cosicchè riavvio e come volevasi dimostrare si pianta tutto.

Allora sperando nella buona sorte, faccio partire il pc dal livecd, eseguo il chroot, mi copio i file su chiavetta, scarico i file e infine riesco a compilare riavvio e come per magia tutto funziona a meraviglia (tranne degli strani messaggi all'avvio che mi dicono che ho dei file con data di modifica nel futuro!!  :Rolling Eyes:  (sono troppo avanti  :Wink:  ) )

Morale della favola non disinstallate niente quando ci sono casi di blocking su pacchetti di sistema senza prima passare dal forum!

(PS: spero davvero che sia tutto a posto!)

cia raga

----------

## lordalbert

ma quindi come si risolve?!

----------

## falko

 *lordalbert wrote:*   

> 
> 
> ma quindi come si risolve?!
> 
> 

 

Sinceramente non lo so...

se non hai ancora rimosso pacchetti di sistema, ti sconsiglio di farlo, aspetta che si calmino le acque e poi vedi  :Wink: 

Io l'ho risolto dando un emerge -uND world facendo il boot da livecd e poi "chroottandomi" nel sistema. Ora pare che tutto funzioni (ho dato anche un revdep-rebuild e è andato tutto ok) ma non penso sia proprio la soluzione migliore

cia

----------

## richard77

 *lordalbert wrote:*   

> 
> 
> ma quindi come si risolve?!
> 
> 

 

Il problema sembra essere solo di wget, per cui io ho risolto scaricando il pacchetto aggiornato senza installarlo (emerge -f).

Ovvero sequenza dei miei comandi (errori compresi:

```

emerge -avtuND world

emerge -C com_err e2fsprogs

emerge -avtuND world

emerge -1av com_err e2fsprogs

emerge -fvtunND world

emerge -C com_err e2fsprogs

emerge -avtuND world

```

Dopo il primo comando: blocco, ok disinstallo i pacchetti che bloccano. Mannaggia non va più wget. 

Reinstallo le librerie, scarico i sorgenti degli aggiornamenti, disinstallo i pacchetti che bloccano e poi installo gli aggiornamenti.

Il problema è che com_err serve a openssl, per cui il disastro c'è solo se wget è installato con il supporto openssl.

----------

## djinnZ

Alle volte mi domando cosa rispondo a fare...   :Twisted Evil: 

Soluzione 1: mascherare tutti gli aggiornamenti che hanno in dipendenza com_err, ss e ext2vattelappesca in attesa che i devel sistemino.

Si applica per chi non sa bene cosa cosa combina o per chi ci lavora con il computer e non può permettersi di rischiare.

Soluzione 2: chi sa quel che fa, chi vuol vedere di dare una mano ai devel e chi semplicemente ci smanetta con la gentoo e non ha problemi se salta qualcosa usa package.provided e fa credere al sistema che com_err ed ss ci siano di modo da provare a vedere cosa si blocca e cosa no.

Soluzione 3: mascherare le nuove versioni di extvattelappesca ed i pacchetti che ne richiedo la dipendenza esplicita. In realtà è una variante della 1.

Soluzione 4: riportare indietro il portage via cvs ed attendere tempi migliori. (questa non la ho provata)

Tutte le prime tre soluzioni funzionano, lo so perchè le uso tutte e tre.

wget vuole com_err ed ss (o meglio le librerie di questi pacchetti) e con le nuove librerie fornite da ext2vattelappesca non compila o fa i capricci su alcuni sistemi (in ogni caso deve essere ricompilato, con le sue dipendenze, indipendentemente da quel che dice revdep-rebuild)

mc vuole sia com_err/ss che extvattelappesca ma non ha problemi (a parte ovviamente ricompilare)

nfs-utils (ultima versione) non vuole per niente com_err ed ss

openssl deve essere ricompilato come sopra

e via dicendo. Non è stato risolto, se non avete avuto problemi non significa che sia tutto a posto, se vi si è sistemato con l'ultimo sync vuol dire che è stato fatto un altro passo avanti.

----------

## Onip

a me wget non ha dato assolutamente problemi e, a guardare dai post in questo topic non capisco assolutamente il perchè?

sarà merito di --as-needed? chi lo sa

```

$ ldd `which wget`

   linux-gate.so.1 =>  (0xb7f23000)

   libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb7ec3000)

   libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb7d7e000)

   librt.so.1 => /lib/librt.so.1 (0xb7d75000)

   libc.so.6 => /lib/libc.so.6 (0xb7c45000)

   libdl.so.2 => /lib/libdl.so.2 (0xb7c41000)

   libpthread.so.0 => /lib/libpthread.so.0 (0xb7c2a000)

   /lib/ld-linux.so.2 (0xb7f24000)

$ eix -e wget 

[I] net-misc/wget

     Available versions:  1.9.1-r5 1.10.2 ~1.11-r1 1.11.1 ~1.11.2 1.11.3 ~1.11.4 {build debug elibc_FreeBSD ipv6 nls socks5 ssl static}

     Installed versions:  1.11.3(14:01:54 25/08/2008)(nls ssl -debug -ipv6 -socks5 -static)

     Homepage:            http://www.gnu.org/software/wget/

     Description:         Network utility to retrieve files from the WWW

```

ad ogni modo posto non per farmi beffe di voi, ma per aggiungere che, invece, mount da dei problemi e se usate bashrc-ng con shmfs dovete disabilitarlo, altrimenti mount non mounta un bel niente.

----------

## ckx3009

come ha detto djinnZ:

in /etc/portage/package.mask

```
=app-crypt/mit-krb5-1.6.3-r4

=sys-fs/e2fsprogs-1.41.2
```

e i problemi spariscono.

----------

## Deus Ex

 *ckx3009 wrote:*   

> come ha detto djinnZ:
> 
> in /etc/portage/package.mask
> 
> ```
> ...

 

Nulla da fare. Il problema persiste, nonostate il mascheramento.

----------

## .:deadhead:.

 *falko wrote:*   

> e logicamnete, prima wget si è incaz. di brutto dicendomi che non trovava la libreria condivisa

 Ah ecco perchè non me ne sono accorto : io uso curl per il download, potrebbe essere un'alternativa :

```

# Using curl

FETCHCOMMAND="/usr/bin/curl --retry 5 -o \${DISTDIR}/\${FILE} \${URI}"

RESUMECOMMAND="/usr/bin/curl -C - --retry 5 -o \${DISTDIR}/\${FILE} \${URI}"

```

nel make.conf e passa la paura!

----------

## Peach

ho appena syncato e nel desiderio di fare un update generale mi sono chiaramente imbattuto in questo problema.

Noto però che c'è questa cosa interessante: con portage 2.2 se gli chiedo un update di world mi risponde alla fine con:

```
...

[ebuild  N    ] sys-libs/e2fsprogs-libs-1.41.2  USE="nls" 479 kB

[ebuild     U ] sys-fs/e2fsprogs-1.41.2 [1.40.9] USE="nls (-static%)" 4,263 kB

[blocks b     ] <sys-fs/e2fsprogs-1.41 ("<sys-fs/e2fsprogs-1.41" is blocking sys-libs/e2fsprogs-libs-1.41.2)

...

[uninstall    ] sys-libs/com_err-1.40.9  USE="nls" 

[blocks b     ] sys-libs/com_err ("sys-libs/com_err" is blocking sys-libs/e2fsprogs-libs-1.41.2)

[uninstall    ] sys-libs/ss-1.40.9  USE="nls" 

[blocks b     ] sys-libs/e2fsprogs-libs ("sys-libs/e2fsprogs-libs" is blocking sys-libs/ss-1.40.9, sys-libs/com_err-1.40.9)

[blocks b     ] sys-libs/ss ("sys-libs/ss" is blocking sys-libs/e2fsprogs-libs-1.41.2)
```

quindi sembra che più che disinstallare e2fsprogs sia da disinstallare com_err e ss

ma poi mi domando, com_err si dovrà anche reinstallare  :Confused:   :Question: 

pensavo quindi di muovermi in questo senso:

pacchettizzo com_err, ss e e2fsprogs e provo la soluzione suggerita da portage, ma facendola a mano... ? che dite?

PS @mods: please aggiornate gli sticky sui problemi come più volte riferito in questo post.

----------

## lsegalla

Io ho avuto questo problema su due macchine: la prima volta ho risolto agevolmente facendo un emerge --fetchonly di tutti i pacchetti, poi ho tirato via ss, com_err e l'altro che non mi ricordo ora... poi li ho riemersi con un emerge --oneshot insieme a tutto il resto.

Sulla seconda evidentemente non era andato a buon fine l'aggiornamento e dopo il riavvio avevo dovuto rifare tutto rientrando in ambiente chroot e ricominciando tutto da lì, ma poi ho risolto sempre nello stesso modo...

Nel mio caso era utile un revdep-rebuild alla fine di tutto.Last edited by lsegalla on Fri Nov 14, 2008 12:24 pm; edited 1 time in total

----------

## cloc3

 *Peach wrote:*   

> 
> 
> ma poi mi domando, com_err si dovrà anche reinstallare  
> 
> 

 

decisamente no.

per questo lo devi aggiungere a package.provided.

se conservi (come è prudente) un tarball di tutti i programmi che disinstalli, potrai verificare che i file di comm_err sono stati inclusi nelle nuove versioni di e2fsprogs ed e2fsprogs-libs. il baco consiste nel fatto che determinati ebuilds, come mit-kerberos, ancora non lo sappiano, producendo certe fittizie inconsistenze nelle dipendenze.

fai dei test con il comando mount prima di riavviare.

----------

## lsegalla

Non vorrei dire una cavolata ma la prima volta che ho tolto com_err ed ss installando pero' e2fsprogs mi sembrava che il sistema non funzionasse... magari mi sbaglio ma mi par di ricordare così. Poi siete voi gli esperti....   :Smile: 

----------

## ckx3009

ss e com_err possono essere sostituiti totalmente da e2fsprogs e e2fsprogs-libs.

quindi

```
emerge --sync

[u]emerge -f e2fsprogs e2fsprogs-libs[/u]

emerge -C ss com_err e2fsprogs

emerge e2fsprogs e2fsprogs-libs
```

e aggiornare app-crypt/mit-krb5 alla versione 1.6.3-r4. 

con questa procedura portage torna ad essere ben funzionante.

fare attenzione a fetchare i pacchetti *prima* di togliere com_err altrimenti, come gia' altri hanno verificato, si sminchia wget e vi tocca scaricare a manina da browser o da livecd i pacchetti necessari.

nel forum internazionale c'e' uno sticky che parla esattamente di questo: https://forums.gentoo.org/viewtopic-t-712898.html

----------

## Onip

 *ckx3009 wrote:*   

> 
> 
> ```
> 
> emerge e2fsprogs e2fsprogs-libs
> ...

 

meglio

```
# emerge -1 e2fsprogs-libs e2fsprogs
```

----------

## ckx3009

tutto dipende se le vuoi nel world o meno. io preferisco avere tutto ben registrato in modo che se devo ricompilare con delle USE o delle CFLAGS nuove posso fare direttamente tutto senza andarmi a cercare nulla, altrimenti bestemmierei ogni santo di ogni calendario terrestre o meno.

----------

## Peach

 *Peach wrote:*   

> ho appena syncato e nel desiderio di fare un update generale mi sono chiaramente imbattuto in questo problema.
> 
> Noto però che c'è questa cosa interessante: con portage 2.2 se gli chiedo un update di world mi risponde alla fine con:
> 
> ```
> ...

 

allora per sicurezza ho fetchato tutto prima di lanciare l'emerge, ho fatto fare il processo interamente ad emerge, e devo dire che la versione 2.2 ha gestito il problema egregiamente, non solo... ma da quello che ho visto ha rimosso le versioni bloccanti alla fine. quindi probabilmente non ci sarebbero stati nemmeno problemi a lanciara l'emerge alla cieca. è solo un'ipotesi chiaramente

----------

## Onip

 *ckx3009 wrote:*   

> tutto dipende se le vuoi nel world o meno. io preferisco avere tutto ben registrato in modo che se devo ricompilare con delle USE o delle CFLAGS nuove posso fare direttamente tutto senza andarmi a cercare nulla, altrimenti bestemmierei ogni santo di ogni calendario terrestre o meno.

 

???

Cosa c'entra ricompilare i pacchetti a piacere con il fatto che sono nel file world? Non è che se un pacchetto non è in world allora non esiste o portage "se ne scorda". Semplicemente world è fatto per dire ad emerge quali pacchetti uno vuole espressamente avere installati ( gnome, fluxbox, amarok, apache per esempio ). Al resto (cioè la gestione delle dipendenze) ci pensa il package manager ( emerge, paludis... ). Per come è pensata gentoo non ha senso mettere tutto in world o roba che non dovrebbe starci, anzi è per certi versi pure controproducente.

Se apri il world file vedrai che è solamente un elenco di atom, non contiene informazioni su USE e CFLAGS: quelle sono nella cache di portage ( /var/cache/pkg ) e ci sono per tutti i pacchetti sia quelli in world sia gli altri.

----------

## cloc3

 *Onip wrote:*   

> Non è che se un pacchetto non è in world allora [...] portage "se ne scorda". 

 

in un certo senso sì.

se quel pacchetto non è dipendenza di qualche altro, non verrà aggiornato automaticamente in presenza di nuove versioni.

sono d'accordo, però con il resto dei tuoi argomenti.

aggiungere a world pacchetti superflui, che sono già dipendenza di altri, ha l'unico risultato di allungare i tempi di calcolo di emerge.

in ragione esponenziale.

regenworld --help

----------

## Onip

 *cloc3 wrote:*   

> 
> 
> in un certo senso sì.
> 
> se quel pacchetto non è dipendenza di qualche altro, non verrà aggiornato automaticamente in presenza di nuove versioni.
> ...

 

se un pacchetto installato non è in world nè è dipendenza di qualcos'altro allora deve essere per forza una dipendenza morta (se si è tenuto il sistema ordinato). Che senso ha aggiornarla a questo punto? Un bel --depclean e si fanno le pulizie di primavera.   :Wink: 

p.s. oltre all'allungarsi dei tempi di calcolo c'è anche il fatto che depclean, appunto, dopo non fa più il suo lavoro come potrebbe e quindi ci si trova con roba installata a muzzo che non è esattamente la mia idea di ordine in un sistema.

poi, chiariamo, gentoo is about choice, quindi ben venga qualunque cosa chiunque faccia sul proprio pc: si fa solo per parlare   :Very Happy: 

----------

## cloc3

 *Onip wrote:*   

> Un bel --depclean e si fanno le pulizie di primavera.  
> 
> 

 

 :Wink:  ecco una cosa da non fare mai, se usi dipendenze morte.

può benissimo essere che qualcuno desideri esplicitamente conservare la versione vecchia di un dato pacchetto. ed esistono cento motivi buoni perché questo possa accadere.

se il programma è lincato staticamente, o se le librerie corrispondenti non sono soggette ad aggiornamento per chiamata di altri programmi, la cosa potrebbe risultare perfettamente stabile.

al limite, si potrebbe persino chiedere ad emerge di non scaricare gli eventuali aggiornamenti di portage per quel pacchetto.

ma sinceramente non mi ricordo più il modo.

----------

## Onip

A quel punto mascheri la versione successiva del tal pacchetto e sei a posto; al limite ti metti l'ebuild specifico in un overlay locale nel caso venga poi rimosso e ti serva ancora.

Ci sono cento buoni motivi per usare certe specifiche versioni di pacchetti, ma ci sono anche i giusti metodi che gentoo mette a disposizione, usiamo quelli piuttosto che le dipendenze morte. Se sono morte un motivo ci sarà pure   :Very Happy:  .

Ad esempio io per matlab che necessita(va) le qt3 mi ero fatto un bell'ebuild farlocco con dentro solo RDEPEND="x11-libs/qt:3" ed ecco che emergendo quello le librerie qt venivano installate e "riconosciute" da portage come dipendenza di qualcosa. Quando l'ho rimosso depclean mi ha anche tolto le qt, perfetto nella mia personale visione di ordine ed eleganza.

Poi, lo vedo anche io, a volte ci si complica la vita per queste finezze e non a tutti sta bene, ma poi non mi si venga a dire che in gentoo le gestione delle dipendenze inverse è schifosa o che il sistema, dopo qualche anno di utilizzo, si è riempito di schifezze.

Saluti!!

p.s. @mods mi sembra che abbiamo "sforato". forse ci starebbe bene il fork()

----------

## cloc3

 *Onip wrote:*   

> ma ci sono anche i giusti metodi che gentoo mette a disposizione
> 
> 

 

si , ma gli strumenti di portage sono molti e non sono univoci.

per fare un esempio, se emergo strace con l'opzione -1, per evitare le versioni successive, sto utilizzando una opzione di portage.

anche se scelgo di mascherare le versioni superiori in /etc/portage utilizzo una opzione di portage.

in questo caso particolare, è probabile che la prima scelta risulti più leggera della seconda. in altri sarà il contrario o sarà indifferente.

è anche evidente che ogni scelta ha le proprie conseguenze, come la rinuncia all'uso di depclean, che tuttavia è strumento radicale e delicato, corredato da un warning molto esplicito in apertura.

 *Onip wrote:*   

> 
> 
> p.s. @mods mi sembra che abbiamo "sforato". forse ci starebbe bene il fork()

 

 :Embarassed:  già.

----------

## lordalbert

Un mio amico ha deciso di lasciare gentoo a causa di questo problema che gli ha sputtanato la distro.

Beh, lui è nuovo di linux, ha semplicemente cancellato i pacchetti senza rifletterci, però non mi sentirei di dargli tutti i torti. Per chi vuole avere un sistema stabile, che non presenti problemi... ricordiamoci che i problemi si hanno con pacchetti segnati come "stable", non mascherati.

----------

## Onip

Purtroppo quando si compila da sorgenti queste cose possono capitare, non dipende sicuramente dai developer; è strutturale. Gentoo è una (meta)distribuzione che richiede attenzione, non c'è niente da fare. Ci sono altre alternative e non è un problema usarle.

----------

## lordalbert

 *Onip wrote:*   

> Purtroppo quando si compila da sorgenti queste cose possono capitare, non dipende sicuramente dai developer; è strutturale. Gentoo è una (meta)distribuzione che richiede attenzione, non c'è niente da fare. Ci sono altre alternative e non è un problema usarle.

 

Non mi sono informato più di tanto sulla questione, ma da quel che ho capito un sw è stato inglobato in un altro o qualcosa del genere... e alcuni ebuild non sono stati aggiornati a questo cambiamento.

----------

## cloc3

 *lordalbert wrote:*   

> 
> 
> Non mi sono informato più di tanto sulla questione, 

 

appunto. non siamo tecnici per giudicare l'operato degli sviluppatori.

spesso l'intervento su alberi di dipendenze complessi può generare problemi di gestione, mentre una inconsistenza temporanea, che ammette comunque alcuni workaround efficaci, può essere una situazione preferibile.

questo non è certo il primo problema di dipendenze, per gentoo e non è assolutamente il più grave. pensa ad esempio i problemi con gli aggiornamenti di gcc o con l'upgrade di expat...

a mio parere, l'incidenza di questi fenomeni sta diminuendo, e le novità della nuova versione di portage offrono servizi per una gestione ancora migliore delle dipendenze. vedi ad esempio l'osservazione di Peach.

in genere, gentoo produce problemi di dipendenze prima della compilazione, le altre distribuzioni dopo.

ti assicuro che se capita di imbattersi in un problema di dipendenze con una distribuzione compilata, sono dolori molto peggiori, perché l'unica soluzione sarebbe ricompilare il software in loco, che è una contraddizione di termini.

il tuo amico ha fatto la sua scelta, ma con un motivo pretestuoso.

----------

## lordalbert

 *cloc3 wrote:*   

> 
> 
> appunto. non siamo tecnici per giudicare l'operato degli sviluppatori.
> 
> spesso l'intervento su alberi di dipendenze complessi può generare problemi di gestione, mentre una inconsistenza temporanea, che ammette comunque alcuni workaround efficaci, può essere una situazione preferibile.
> ...

 

Che sia chiaro, non voglio criticare gli sviluppatori, ma dipende la definizione di "temporanea"  :Smile:  Se non sbaglio è da un po che c'è il problema.

Ma a parte questo, non voglio certo fare fretta, quello che mi sono chiesto è: Non è meglio prima intervenire su pacchetti mascherati (keyword), e una volta verificato il tutto, smascherare la nuova versione?

 *Quote:*   

>  e le novità della nuova versione di portage offrono servizi per una gestione ancora migliore delle dipendenze. vedi ad esempio l'osservazione di Peach. 

 

Stavo notandolo anche io. Sembrano novità alquanto interessanti.

 *Quote:*   

> 
> 
> in genere, gentoo produce problemi di dipendenze prima della compilazione, le altre distribuzioni dopo.
> 
> ti assicuro che se capita di imbattersi in un problema di dipendenze con una distribuzione compilata, sono dolori molto peggiori, perché l'unica soluzione sarebbe ricompilare il software in loco, che è una contraddizione di termini.

 

Si si, quello è vero. Nei giorni scorsi ho provato debian. I driver per la mia scheda ethernet sono stati aggiunti solo nella versione .27 del kernel, quindi ho dovuto usare quel kernel compilato da me, e i problemi si sono verificati per esempio con virtualbox, in cui il pacchetto modules è stato compilato per il kernel .26  Nulla di particolare, ma ho dovuto ricompilare il pacchetto in locale. Insomma, voglio dire che i problemi si verificano un po' ovunque, però credo fosse stato più saggio prima introdurre i pacchetti mascherati, e poi, una volta verificato che non ci siano problemi, smascherarli

----------

## Onip

 *lordalbert wrote:*   

> Non è meglio prima intervenire su pacchetti mascherati (keyword), e una volta verificato il tutto, smascherare la nuova versione?

 

Questo è esattamente quello che i dev cercano di fare, purtroppo a volte qualche uovo va rotto comunque. Questo ne è un esempio ( 2 pacchetti separati sono stati inglobati in uno solo nuovo) e l'upgrade di expat un altro.

Daltronde se wget linka contro ad uno dei pacchetti rimossi i dev non possono intervenire più di tanto.

----------

## ckx3009

riferito al penultimo post di cloc3:

io non ho mai usato l'opzione -1 nei miei emerge e tutte le volte che ho usato --depclean, non ho mai dovuto ricompilare nulla con revdep-rebuild. 

probabilmente e' anche perche' guardo sempre la lista completa dei pacchetti che lui vuole eliminare, e spesso capita che alcuni li proteggo dalla rimozione perche' mi servono o mi sono comodi, come alcune versioni del kernel o 2 versioni di gcc insieme.

per quanto riguarda le librerie che hanno versioni piu' recenti di quelle richieste dai pacchetti installati, basta vedere cosa comporta l'aggiornamento: se ci sono incompatibilita' tra la libreria e il pacchetto che l'ha in dipendenza, basta mascherare nel package.mask l'aggiornamento alla libreria: nulla di anormale.

poi forse anche questo metodo avra' i suoi contro, pero' fino ad ora non ne ho trovati.

riferito a cio' che ha detto lordalbert:

c'e' anche da dire che invece di andare a prendere a testate il proprio albero di dipendenze andando a unmergere ogni pacchetto che crea conflitto, si puo' anche aspettare che qualcuno di piu' esperto parli in forum. 

io personalmente ho aspettato diversi giorni avendo "emerge -uDNav world" bloccato da questo problema, pero' non sono andato a disinstallare nulla (peccato poi che mi si e' corrotto il file system e ho avuto altri problemi legati a questo, ma ho risolto).

basta avere un minimo di accortezza in quel che si fa.

----------

## lordalbert

 *Onip wrote:*   

>  *lordalbert wrote:*   Non è meglio prima intervenire su pacchetti mascherati (keyword), e una volta verificato il tutto, smascherare la nuova versione? 
> 
> Questo è esattamente quello che i dev cercano di fare, purtroppo a volte qualche uovo va rotto comunque. Questo ne è un esempio ( 2 pacchetti separati sono stati inglobati in uno solo nuovo) e l'upgrade di expat un altro.
> 
> Daltronde se wget linka contro ad uno dei pacchetti rimossi i dev non possono intervenire più di tanto.

 

in casi inevitabili, potrebbero inserire un messaggio di "istruzioni", che spieghi per lo meno come comportarsi.

Se uno deve prima fare il fetch, poi eliminarne 2, e poi aggiornare, non c'è nulla di male in tutto ciò! Sono cose capibili. Però se non ci fosse stato il forum io non sapevo come risolvere. Magari utenti più esperti di me non avrebbero avuto problemi, però secondo me le soluzioni sono 2. 1) Far fare tutto il lavoro a portage (quello del fetch, disinstallare, e reinstallare) 2) Mettere 2 righe in cui spiegano come comportarsi.

Forse, da quel che mi sembra di aver capito, il primo punto è stato introdotto nel nuovo portage

----------

## bandreabis

Domanda per ckx3009:

come faccio a proteggere dal emerge --depclean le diverse versioni di kernel?

Andrea

----------

## djinnZ

inserendole nel world come sys-kernel/vattelappesca-sources:slot o =sys-kernel/vattelappesca-sources-versione o con emerge -n =sys-kernel/vattelappesca-sources-versione.

----------

## bandreabis

 *djinnZ wrote:*   

> inserendole nel world come sys-kernel/vattelappesca-sources:slot o =sys-kernel/vattelappesca-sources-versione o con emerge -n =sys-kernel/vattelappesca-sources-versione.

 

Sta volta sono riuscito a farmi capire... WOW.   :Laughing: 

Grazie, ero stufo di unmergere a mano dopo un 

```
emerge --depclean -p
```

----------

## ckx3009

```
# emerge --depclean

 * Always study the list of packages to be cleaned for any obvious

 * mistakes. Packages that are part of the world set will always

 * be kept.  They can be manually added to this set with

 * `emerge --noreplace <atom>`.
```

----------

## djinnZ

[censura]  :Laughing: 

----------

## bandreabis

[censura]  :Razz: 

Oh, finalmente ho capito come utilizzare quel messaggio.

Grazie djinnZ, grazie ckx3009.

----------

## ckx3009

 *djinnZ wrote:*   

> [censura] 

 

manca il :rotfl: 

era solo per specificare che non mi sono inventato il comando, ma che e' scritto bello bello e chiaro chiaro, e che appare proprio quando serve  :Razz: 

----------

