This is mostly the same as bug 760783 (see also its huge list of See Also bugs), but I'd like this one to have very narrow scope: something with no ebuild available in @selected or @world file. I think we need to revisit some of the "friendly" behaviour chosen in the past now that we have slot rebuilds. The pattern is something like: - User has years' worth of junk in their world file (/var/lib/portage/world) - One or more of those packages get removed from the tree - One of those packages bar has a := dep on libfoo - libfoo changes its subslot one day - bar can't be rebuilt and leads to confusing world upgrade output I tend to recommend people try 'emerge -pev @world --backtrack=0' to find these, but they shouldn't have to.
Created attachment 866174 [details, diff] hack.patch Not going to use the attached patch, but it leads to the rightish outcome: ``` emerge: there are no ebuilds to satisfy "app-misc/i-do-not-exist". (dependency required by "@selected" [set]) (dependency required by "@world" [argument]) ``` but I'd prefer something like this instead, reusing the existing message which doesn't get triggered for this case: ``` !!! Problems have been detected with your world file !!! Please run emaint --check world !!! Ebuilds for the following packages are either all !!! masked or don't exist: app-misc/foo ``` I'm aiming for ^^. (With no patches, we get absolutely no output for this.)
(In reply to Sam James from comment #0) > This is mostly the same as bug 760783 (see also its huge list of See Also > bugs), but I'd like this one to have very narrow scope: something with no > ebuild available in @selected or @world file. > > I think we need to revisit some of the "friendly" behaviour chosen in the > past now that we have slot rebuilds. > > The pattern is something like: > - User has years' worth of junk in their world file (/var/lib/portage/world) > - One or more of those packages get removed from the tree > - One of those packages bar has a := dep on libfoo > - libfoo changes its subslot one day > - bar can't be rebuilt and leads to confusing world upgrade output > Ah, sorry, I should've added: - Users think Gentoo is "much harder" now with "tonnes of conflicts" because 15 years ago, Portage would happily let installed packages get broken in this case. :)
Currently I rely on a message from eclean-dist warning about exactly the same issue... I am not sure if its check could be borrowed from there to get a similar warning at world update stage :/ I think its check resides in pym/gentoolkit/package.py from gentoolkit under the format_package_location section
