| Summary: | emerge --depclean (-c) preserves all alternatives (||) for virtual package | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Martin von Gagern <Martin.vGagern> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | trivial | CC: | ajak, bkohler, esigra |
| Priority: | Normal | ||
| Version: | 2.2 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 155723 | ||
(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). 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. (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. Definitely seems fixed now. |
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.