Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 368093 - emerge --depclean (-c) preserves all alternatives (||) for virtual package
Summary: emerge --depclean (-c) preserves all alternatives (||) for virtual package
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal trivial (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 155723
  Show dependency tree
 
Reported: 2011-05-19 20:49 UTC by Martin von Gagern
Modified: 2014-08-01 21:27 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin von Gagern 2011-05-19 20:49:54 UTC
I had lapack-reference on my system, and wanted to replace it with lapack-atlas. Emerged the latter, and wanted to safely clean the former using --depclean. However, it seems that portage 2.2.0_alpha33 will preserve all members from a list of alternatives:

# emerge -cv lapack-reference

Calculating dependencies... done!
  sci-libs/lapack-reference-3.2.1-r1 pulled in by:
    virtual/lapack-3.1

>>> No packages selected for removal by depclean

I've started using --depclean instead of --unmerge after my experiences with bug #340173. I still think that the combination of --unmerge --complete-graph would be the more intuitive way to specify what I want to achieve here.

This issue has some relation to bug #136178. But I think there should be a difference between a whole-system cleanup, and a selective cleaning of a single atom. When I specify a single atom to --depclean, I want to make sure it is safe to remove it, and if so, actually do remove it. According to the alternative dependencies, it is safe, so the unmerge should imo proceed.

The workaround for this issue is obvious: "emerge -cv" to ensure it's really only the virtual which requires the package in question, have a look at the virtual ebuild to ensure it is satisfied in some other way, then "emerge -C" the package in question. This workaround doesn't perform the check for library consumers which --depclean does, though.
Comment 1 Zac Medico gentoo-dev 2011-05-19 21:11:57 UTC
(In reply to comment #0)
> I've started using --depclean instead of --unmerge after my experiences with
> bug #340173. I still think that the combination of --unmerge --complete-graph
> would be the more intuitive way to specify what I want to achieve here.

The behavior that you want makes sense for --depclean, so we should just fix that.

> This issue has some relation to bug #136178. But I think there should be a
> difference between a whole-system cleanup, and a selective cleaning of a single
> atom. When I specify a single atom to --depclean, I want to make sure it is
> safe to remove it, and if so, actually do remove it. According to the
> alternative dependencies, it is safe, so the unmerge should imo proceed.

We can make the depgraph behave correctly by applying masks to the package(s) that are matched by arguments. These masks will cause it to avoid adding these packages to the graph when evaluating || choices.

> The workaround for this issue is obvious: "emerge -cv" to ensure it's really
> only the virtual which requires the package in question, have a look at the
> virtual ebuild to ensure it is satisfied in some other way, then "emerge -C"
> the package in question. This workaround doesn't perform the check for library
> consumers which --depclean does, though.

BTW, in portage-2.2.0_alpha34 the library consumer check is disabled by FEATURES=preserved-libs (see bug 286714).
Comment 2 Ben Kohler gentoo-dev 2014-08-01 19:45:41 UTC
Is this still an issue? I don't believe current portage versions behave this way, they will remove all but one of the virtual providers, assuming one or none is in world.
Comment 3 Martin von Gagern 2014-08-01 21:27:51 UTC
(In reply to Ben Kohler from comment #2)
> Is this still an issue? I don't believe current portage versions behave this
> way, they will remove all but one of the virtual providers, assuming one or
> none is in world.

Sorry, don't have time to test for at least a week, probably more. If you can't reproduce the issue with lapack, feel free to close FIXED. I'd reopen if I'd ever encounter this again.