Hello, I have been fighting with an "emerge -uDN world" update in one of the systems I didn't update for some months. At the end, all the conflicts were caused by an old package that was removed some months ago that was still requiring python3.7 and, as a consequence, was preventing the upgrade. The errors where misleading (but that is a different old bug hard to fix) pointing to boost consumers or qt... I realized that maybe it would be nice if "emerge -vuDN world" would have warned me about some packages being pulled in even if their ebuild was removed from all the repos I have in my system (but package.mask entry dropped as it was dropped some months ago) Thanks a lot
Would this be solved with a depclean after world upgrades? Or am I misunderstanding?
(In reply to Sam James from comment #1) > Would this be solved with a depclean after world upgrades? Or am I > misunderstanding? It won't removed it if it's in your world file. The behavior related to bug 266836 and bug 651018 is related because it can prevent updates, causing older things to linger around.
Rethinking about this, I think that maybe it would be enough with adding a warning when running depclean and packages without existing ebuilds are present in the system
The warning would also be really useful when updating a system after some months as , most of the times, package.mask entries are removed upon removal. Thanks a lot
I'm sorry, yes, I understand you now! Aside: emerge -ep @world --backtrack=0 is quite good at exposing all of these, but people shouldn't have to do that.
(In reply to Pacho Ramos from comment #4) > The warning would also be really useful when updating a system after some > months as , most of the times, package.mask entries are removed upon removal. > > Thanks a lot I second Pacho's comment. But I would say a warning is not really helpful, as portage is already very verbose by default. (In reply to Sam James from comment #5) > I'm sorry, yes, I understand you now! > > Aside: emerge -ep @world --backtrack=0 is quite good at exposing all of > these, but people shouldn't have to do that. Running this, for me, returns this: emerge: there are no ebuilds to satisfy "sys-kernel/gentoo-sources:5.15.80". (dependency required by "@selected" [set]) (dependency required by "@world" [argument]) But there is a 5.15.110 in tree. I guess kernel sources should use slots for middle version? I think @world should never store the package version. And for kernel, the slots would be useful for LTS versions one might want to use. More on the topic, I think there should be a standard command to upgrade the system. Say have 'emerge --upgrade' with no package arguments should do what portage maintainers think is necessary to upgrade the system. If that involves @world, @system or @installed is up to Portage. Ideally it would: - Upgrade what it could with no breakage - Preserve libs for packages that are not in tree anymore. - Give you a list of what can't upgraded at the end.
