View previous topic :: View next topic |
Author |
Message |
cloc3 Advocate
Joined: 13 Jan 2004 Posts: 4807 Location: http://www.gentoo-users.org/user/cloc3/
|
Posted: Fri Jul 26, 2024 7:36 pm Post subject: aggiornamento battagliato. |
|
|
sto cercando di risistemare una vecchia gentoo box con il metodo del bastone e della carota.
... soprattutto, le bastonate le sto prendendo io.
per esempio:
Code: |
cloc3 ~ # emerge -pv -uDN @world --backtrack=30
These are the packages that would be merged, in order:
Calculating dependencies ......... .... ... .. ..... ....... done!
Dependency resolution took 253.57 s (backtrack: 1/30).
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
kde-frameworks/kidletime:5
(kde-frameworks/kidletime-5.116.0:5/5.116::gentoo, ebuild scheduled for merge) USE="X wayland -debug -doc -xscreensaver" ABI_X86="(64)" pulled in by
(no parents that aren't satisfied by other packages in this slot)
(kde-frameworks/kidletime-5.115.0:5/5.115::gentoo, installed) USE="X wayland -debug -doc -xscreensaver" ABI_X86="(64)" pulled in by
>=kde-frameworks/kidletime-5.106.0:5/5.115= required by (kde-plasma/kwin-5.27.11-r1:5/5::gentoo, installed) USE="accessibility (caps) handbook lock multimedia plasma screencast -debug -gles2-only -test" ABI_X86="(64)"
^^^^^^^^^
It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously.
For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.
emerge: there are no ebuilds to satisfy ">=dev-qt/qtgui-5.15.9:5/5.15.13=[wayland]".
(dependency required by "kde-frameworks/kidletime-5.115.0::gentoo" [installed])
(dependency required by "kde-plasma/kwin-5.27.11-r1::gentoo" [installed])
(dependency required by "kde-plasma/plasma-desktop-5.27.11::gentoo" [installed])
(dependency required by "kde-plasma/plasma-meta-5.27.11-r1::gentoo" [installed])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])
|
per superare questo conflitto, basterebbe ricompilare manualmente il pacchetto kde-frameworks/kidletime, che attualmente è lincato alla vecchia versione di dev-qt/qtgui e che emerge, per qualche ragione, non propone di ricompilare automaticamente (in alternativa, si potrebbe anche eliminare provvisoriamente il pacchetto).
il guaio è che, con tutta probabilità, al giro successivo, il pacchetto kidletime sarà sostituito da un altro pacchetto ribelle con lo stresso problema e poi da un altro e da un altro ancora.
esiste un modo sistematico per mettere ordine in queste situazioni travagliate? _________________ vu vu vu
gentù
mi piaci tu |
|
Back to top |
|
|
pierino_89 Guru
Joined: 03 Oct 2009 Posts: 524
|
Posted: Wed Aug 14, 2024 1:20 pm Post subject: |
|
|
È abbastanza probabile che saltino fuori altri pacchetti problematici... In ~amd64 capita spesso durante gli aggiornamenti delle librerie qt, soprattutto se l'ultimo aggiornamento non è freschissimo.
Per la mia personale esperienza puoi usare due metodi in base alla situazione e ai gusti.
Metodo 1 - pazienza e olio di gomito
Controlla i messaggi - in questo caso hai due problemi: qtgui con use non gradite e la versione di kidletime.
La seconda è abbastanza facile da sistemare, l'ultima versione non la chiama nessuno per cui basta mascherarla), in certi casi conviene direttamente mascherare tutti i pacchetti di kde di una versione specifica in modo da forzare un aggiornamento senza salti.
Per la prima probabilmente è necessario fare un upgrade/rebuild di qtgui finché non ottieni use adeguate.
Se non è possibile ottenere use adeguate, probabilmente è necessario fare l'aggiornamento/il rebuild di chi le chiama a catena (eventualmente spegnendo a mano le use non disponibili).
Vai avanti a mask e rebuild finché non è contento. Quando l'aggiornamento arriva al fondo, togli i mask e riparti.
Metodo 2 - azzera e ricostruisci
Avvia un altro DE (per esempio a me piace blackbox), rimuovi tutti i pacchetti molesti (librerie qt comprese) e procedi con l'aggiornamento.
Quasi sicuramente si romperà qualcosa nel frattempo, da cui la necessità di un altro DE.
Tendenzialmente se non vengono rimossi pacchetti nel world verranno nuovamente tirati dentro in automatico - meglio comunque appuntarsi cosa si toglie. È anche una buona occasione per fare pulizia del file world... _________________ Linux registered user 461710 |
|
Back to top |
|
|
cloc3 Advocate
Joined: 13 Jan 2004 Posts: 4807 Location: http://www.gentoo-users.org/user/cloc3/
|
Posted: Wed Aug 14, 2024 5:32 pm Post subject: |
|
|
pierino_89 wrote: | Metodo 1 - pazienza e olio di gomito
|
grazie per la risposta, che mi fa molto piacere, anche se, oggettivamente, è un po' tardiva.
sono già arrivato a una quadra, con un salto al supermercato per procurarmi una cassa di olio di gomito.
detto che questo genere di fenomeni è comprensibile, per una box abbandonata da un po' troppo tempo, il punto che mi ha indotto ad aprire un post è che, in questo caso, avevo l'impressione di trovarmi in una situazione in cui l'utente, leggendo il messaggio d'errore del programma, capiva il da farsi, ma il programma si bloccava lo stesso.
non dovrebbe andare così. se capisce l'utente, dovrebbe capire anche il programma.
(se non ricordo male) infatti, ho ricompilato forzosamente kde-frameworks/kidletime, senza cambiare versione e il problema si è spostato al programma successivo che aveva un guaio simile ... _________________ vu vu vu
gentù
mi piaci tu |
|
Back to top |
|
|
pierino_89 Guru
Joined: 03 Oct 2009 Posts: 524
|
Posted: Wed Aug 14, 2024 10:12 pm Post subject: |
|
|
Immaginavo, ma è relativo: potrei essere in anticipo sul prossimo aggiornamento
Non sono sicuro che sia una situazione che possa dipanare il sistema in automatico.
Quando si segue la regolare routine di aggiornamento, c'è un filo logico da seguire e il sistema sa già che strada prendere. Quando mancano degli step, il sistema si fa ingolosire e cerca immediatamente di saltare all'ultimo.
Il sistema però non sa che in certi casi esistono percorsi di migrazione da una release all'altra più o meno espliciti (vedi Gitlab per fare un esempio).
In questi casi (non solo su Gentoo) ho sempre visto i gestori di pacchetti accartocciarsi e chiedere all'utente di risolversela in qualche modo. I più generosi riportavano il link alla documentazione.
La peculiarità di KDE non è tanto il problema in sé, ma il numero di pacchetti coinvolto nella questione e il fatto che non mi risulta esserci un "percorso di migrazione" documentato a parte per le major release.
Forse si potrebbe creare uno script che in qualche modo automatizzi l'attività di (s)mascherare un'intera versione specifica, in modo da evitare di trattare ogni singolo pacchetto... _________________ Linux registered user 461710 |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|