| Summary: | media-libs/gst-plugins-0.8.11 emerge or unmerge ? | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Christophe PEREZ <chris> |
| Component: | Current packages | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | InVCS |
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 136244, 142283 | ||
| Attachments: |
emerge_pretend_debug_depclean.log
remove slots that aren't explicitly pulled into the depgraph remove slots that aren't explicitly pulled into the depgraph remove slots that aren't explicitly pulled into the depgraph |
||
|
Description
Christophe PEREZ
2006-07-15 21:52:21 UTC
*** Bug 140592 has been marked as a duplicate of this bug. *** *** This bug has been marked as a duplicate of 4698 *** *** This bug has been marked as a duplicate of 4698 *** Please attach the output of `emerge --pretend --debug --depclean`. Created attachment 91918 [details]
emerge_pretend_debug_depclean.log
It seems that gst-plugins-0.8.11 isn't pulled into the dependency graph because gst-plugins-oss-0.8.11 and gst-plugins-alsa-0.8.11 aren't pulled in either. That makes we wonder why depclean doesn't want to remove the other two. I'll have to research that some more... They're all in there... $ grep -E '^ebuild' depclean-debug | grep gst ebuild: media-libs/gstreamer-0.10.8 ebuild: media-libs/gst-plugins-base-0.10.8 ebuild: media-plugins/gst-plugins-alsa-0.10.4 ebuild: media-plugins/gst-plugins-oss-0.10.2 ebuild: media-plugins/gst-plugins-xvideo-0.10.4-r1 ebuild: media-plugins/gst-plugins-x-0.10.4 They're all there, neglecting versions. Perhaps we should modify depclean so that it removes all versions that aren't explicitly pulled into the depgraph. We could make an exception for packages in the world and system sets, keeping all slots (whether they're pulled into the depgraph or not). (In reply to comment #7) > We could make an exception for packages in the world and system sets, keeping > all slots (whether they're pulled into the depgraph or not). Actually, I wouldn't exempt system packages. But world packages should be exempt since there's currently no way of know which slots the user wants to keep (atoms in the world file aren't specific enough). Created attachment 91960 [details, diff]
remove slots that aren't explicitly pulled into the depgraph
This patch will make depclean remove slots that aren't explicitly pulled into the depgraph. It exempts both system and world packages, since it's not possible to know which slots of those that the user wants to keep. It would be possible to remove the exemption for system packages if we change the behavior so that system packages may be added to the world file when the user explicitly merges them.
Created attachment 91962 [details, diff]
remove slots that aren't explicitly pulled into the depgraph
This fixes a bug in the previous patch so that atoms from the world/system sets are correctly compared with the unversioned atoms from the explicitly required set.
Created attachment 91963 [details, diff]
remove slots that aren't explicitly pulled into the depgraph
I've fixed one more bug and now it seems to work well. It should cause depclean to remove the unneeded gst-plugins-oss-0.8.11 and gst-plugins-alsa-0.8.11 slots (if those packages aren't listed in /var/lib/portage/world).
This is fixed in svn r3914. The other side of this is that it may be necessary to alter the depgraph behavior so that it doesn't pull in unnecessary slots as part of an upgrade. This has been released in 2.1.1_pre3-r2. |
