Summary: | portage doesnt clean up non-standard INFOPATHs (like sys-devel/binutils) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | minor | Keywords: | InVCS |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=672408 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 373933 |
Description
Toralf Förster
2010-06-08 16:03:02 UTC
Hi, can you please run `equery belongs ...` or `qfile ...` on these files and post the output, maybe they belong to some other ... I can confirm this with /usr/share/binutils-data/x86_64-pc-linux-gnu/2.20/info/dir etc. And they don't belong to anything. Reso/Wont? This gives nothing : tfoerste@n22 ~ $ ls /usr/share/binutils-data/i686-pc-linux-gnu/*/info/dir | xargs -n 1 qfile althought at least this is installed: tfoerste@n22 ~ $ equery l binutils * Searching for binutils ... [IP-] [ ] sys-devel/binutils-2.20.1-r1:0 binutils has nothing to do with the creation/management of that file *** Bug 377153 has been marked as a duplicate of this bug. *** The INFOPATH settings come from /etc/env.d/05bintils, which is probably generated by binutils-config. When we're unmerging directories, we can check if they are in INFOPATH and if the "dir" file is the only remaining contents, and in that case we can remove it so that the parent will be unmerged. This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=3acce846c43eed7feefd3ab9c47dd172a83ae1db i'm not sure about that. sounds a bit sketchy. since binutils-config already has an --uninstall option to clean up the stuff it generated, seems like it'd make sense to just add this to the list. I've made it tread any directory named "info" as a candidate: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=2c92ae3c7ddb903bcffe96046cebe8106439e86b that i can live with ;) This is fixed in 2.1.10.11 and 2.2.0_alpha51. |