| Summary: | "emerge clean" not finding all packages properly | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Maik Schreiber <blizzy-keyword-gentoo_bugs2.a8a736> |
| Component: | Unclassified | Assignee: | Daniel Robbins (RETIRED) <drobbins> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | blizzy-keyword-gentoo_bugs2.a8a736, dave |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Maik Schreiber
2002-06-30 16:33:48 UTC
I forgot to say that this is with Portage 2.0.8. i can verify that this happens for me as well... happens mostly on ebuild revision updates but sometimes on buxfix, ie 1.1.1 to 1.1.2, revisions when the api's do not change so packages depending on these should not require the old version. this has happened for me since 1.8.x of portage dave I think this is only happening with packages that do not fall into either of these two categories: - the package is a "system" package (/etc/make.profile/packages, lines with leading "*") - the package is a "world" package (/var/cache/edb/world) All those packages that do not fall into either of these categories are simple dependencies for other packages that can only be found when scanning through *every* installed package searching for updated dependencies. Only scanning through "system" or "world" packages is not enough, since a dependency could also be updated for a non-world, non-system package as well. Blizzy, see if you can reproduce this with Portage 2.0.11. If so, reply to this bug; otherwise close it. Here's what I have found out with Portage 2.0.11: I made two packages, fake1-1.0 and fake2-1.0. fake2 depends on fake1 (any version). I installed fake2 using "emerge fake2", pretending I'm not interested in any dependencies, just that fake2 is installed. Portage correctly installed fake1-1.0 and fake2-1.0. I then created fake1-1.1 and fake2-1.1. Now comes the interesting part. "emerge fake2" installs only fake2-1.1, not fake1-1.1. To the contrary, "emerge -u fake2" installed fake1-1.1, too. In any case, "emerge -p clean" showed correct results, including old installed versions of fake1. I don't know if Portage is behaving correctly by not paying attention to updated dependencies when not using the -u flag. Shall I file another bug report? Today I've updated from glibc-2.2.5-r4 to glibc-2.2.5-r5. After that, "emerge -p clean" did not show anything to be cleaned at all, but glibc clearly is a core package. This was with Portage 2.0.13 this time. Today with Portage 2.0.18: Updated from sys-apps/which-2.13 to 2.14. Output from "emerge -p clean" doesn't show anything in regard to sys-apps/which. This should be fixed in Portage 2.0.19. Sorry to reopen this one, but... Portage 2.0.20: I had dev-java/jikes-1.15 installed, which was also registered in "world". I then updated to jikes-1.16. "emerge -p clean" doesn't show it, though. This is the output from "emerge -p prune":
>>> These are the packages that I would unmerge:
app-shells/bash-completion
selected: 20020624
protected: 20020727
omitted: none
dev-java/jikes
selected: 1.15
protected: 1.16
omitted: none
sys-libs/db
selected: 1.85-r1
protected: 3.2.3h-r4
omitted: none
As you can see, I even forgot bash-completion, which is also in "world" and
which I've updated yesterday.
Portage 2.0.21, output from "emerge -p prune": >>> These are the packages that I would unmerge: app-shells/bash-completion selected: 20020624 protected: 20020727 omitted: none sys-libs/db selected: 1.85-r1 protected: 3.2.9 omitted: none sys-apps/which selected: 2.13 protected: 2.14 omitted: none dev-java/jikes selected: 1.15 protected: 1.16 omitted: none dev-libs/cyrus-sasl selected: 1.5.27-r4 protected: 2.1.5-r2 omitted: none dev-libs/glib selected: 1.2.10-r4 protected: 2.0.4-r1 omitted: none Output from "emerge -p clean": >>> These are the packages that I would unmerge: >>> No outdated packages were found on your system. We don't clean unslotted ebuilds, which is what was confusing blizzy. I'm closing this bug. |
