I like the way how FreeBSD handles old libraries through moving them to a special directory. I would like it, if portage would do the same (e.g. to /usr/lib[64]/old), that would help to keep track of which libraries are old and orpahn. Reproducible: Always
This is like the "quarantine directory" mentioned in bug 286714, comment #0.
Abbreviated notes from discussion in #gentoo-portage after I cried for two days about how I stupidly depcleaned my only installed gcc and killed my system: < floppym> A complication with gcc is that it populates /etc/ld.so.conf.d based on the currently installed slots. < floppym> So if the libs were kept in place, it would still break unless you updated ld.so.conf manually. < zmedico> right < zmedico> and we don't want portage to add multiple dirs in there < zmedico> just add one dir for orphans < zmedico> and copy them all there < floppym> Could hit conflicts if multiple versions of gcc are removed at once. < floppym> Each version installs its own libgcc_s.so.1, for example. < floppym> I guess it is only relevent when you remove the last gcc version though. < floppym> Otherwise there is no orphan. tl;dr add a new dir for all orphans to /etc/ld.so.conf.d, move in use orphan libs to that dir. slot is not a concern as a lib is only orphan when the last slot is removed.
(In reply to comment #0) > I would like it, if portage would do the same (e.g. to /usr/lib[64]/old), > that would help to keep track of which libraries are old and orpahn. In order to ensure that the separate-/usr-without-initramfs people can boot, our special directory(s) need to be under /lib* (rather than /usr/lib*). Would /lib*/preserved would be good? We could have it create the directory(s) and add them to /etc/ld.so.conf.d/ dynamically, then remove them automatically when they are not needed anymore.
> In order to ensure that the separate-/usr-without-initramfs people can boot, > our special directory(s) need to be under /lib* (rather than /usr/lib*). > Would /lib*/preserved would be good? We could have it create the > directory(s) and add them to /etc/ld.so.conf.d/ dynamically, then remove > them automatically when they are not needed anymore. I respectfully refuse to acknowledge the first part of this comment. The dynamic part, however, I think is more effort than it is worth. what is the harm in one extra dir in ld.so.conf.d? Does it really matter if an empty dir is in there? I would imagine not, and the simplest solution being the best I suggest we don't randomly add/remove the orphan dir.
(In reply to comment #4) > The dynamic part, however, I think is more effort than it is worth. what is > the harm in one extra dir in ld.so.conf.d? It's one dir per ABI. There's no harm in having extra dirs there, but if they don't exist for any reason, then we need portage to be able to create them and add them to ld.so.conf.d dynamically. >Does it really matter if an empty > dir is in there? I would imagine not, and the simplest solution being the > best I suggest we don't randomly add/remove the orphan dir. Well, I guess there's no reason to remove the directory(s) after they've been created. Portage needs to be able to create them dynamically though, for flexibility.
(In reply to comment #2) I'm not sure what happend with the mentioned gcc installation, but in regard to gcc(-installation-changes), there is bug #433161 (with a patch) which might help.
> I'm not sure what happend with the mentioned gcc installation, but in regard > to gcc(-installation-changes), there is bug #433161 (with a patch) which > might help. To clarify my original problem it was STUPIDITY not a bug. Although the bug appears related to what happened to me it is not related at all. One of my team members changed our profile and removed our stabilization of gcc-4.6 before it was stable on arm, this caused my arm system to depclean my only copy of gcc which is completely my fault. My interest in this bug is protecting the user from stupidity, if it also protects the user from other problems that's great too.
