Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 698972 - sys-apps/portage feature request: --uninstall-leaves
Summary: sys-apps/portage feature request: --uninstall-leaves
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
Depends on:
Reported: 2019-10-31 02:28 UTC by Kent Fredric (IRC: kent\n) (RETIRED)
Modified: 2019-10-31 02:28 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2019-10-31 02:28:38 UTC
One of the really annoying problems you face when helping somebody upgrade a system that hasn't sync'd in a few years, is they have a lot of "leaf" dependencies still in the vdb, which require old versions of things.

Portage, being unable to upgrade these at all, seems to default instead to making these hard blockers.

So after lots of iteration, one user I'm helping has had to manually invoke `emerge -C` on a few dozen packages that are no longer possible to keep working, in order to eliminate all the inwards pointing deps that cause portage to fail.

Instead, what would be nice is an option to tell portage to search upwards in the dependency graph to find these leaves, and then:

1. If the leaf is no longer available in portage at all, but not mentioned in @world, schedule it for removal
2. If the leaf is no longer available in portage at all, but *is* mentioned in @world, make it a clear error case informing the user (apropos of)

"while trying to upgrade X, it seems you have <foo> installed still, which is stuck requiring an old version of X,
  but as X is no longer in portage, reinstalling it is now impossible: If you wish to remove this package, remove it from @world first with  "emerge --deselect <foo>", and then rerun this emerge, if you still want this package, you're gonna need to either provide a way to reinstall it (overlay?), or just be satisifed with a system that can't be upgraded (EDISCOURAGED)"

This would approximate a more finely grained depclean in some ways, but only cleaning deps in order to get things working.

And importantly, this should be designed to work in places where depclean currently can't be run prior to the merge.

For example:

   You have ImportantPackage 1.0 installed
   ImportantPackage 1.0 requires UtterlyUselessThing 1.0
   UtterlyUselessThing 1.0 requires OldVersionOfThing 0.1

   You want to install ImportantPackage 2.0, which requires OldVersionOfThing 2.0

Here, in my experience, this becomes a blocker, as you can't upgrade OldVersionOfThing because UtterlyUselessThing is still installed.

But you can't depclean it prior to upgrade, as ImportantPackage 1.0 is still installed, requiring it.

When the solution should be:

   - Remove UtterlyUselessPackage entirely
   - Permitting OldVersionOfThing to upgrade
   - Permitting ImportantPackage to upgrade

As is, no volume of --backtrack=1000 does this.