I have just noticed this in summary.log: >>> Messages generated by process 30829 on 2012-06-23 13:43:27 CEST for package net-wireless/bluez-4.101: ERROR: postrm One or more symlinks to directories have been preserved in order to ensure that files installed via these symlinks remain accessible: /lib /usr/lib Probably no warning should be shown for this kind if "system" links that will always need to be preserved but, apart from that, I am unsure about tagging as "errors" this kind of problem, I would downgrade them to simply "einfo" Thanks a lot Reproducible: Always
Yeah, we'll have to whitelist /lib and /usr/lib.
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e0fa8f389867d78438451ed4a8b1af1ea89b65b6
This is fixed in 2.1.11.1 and 2.2.0_alpha112.
About tagging this message as errors, what is the way to fix them when we get that errors and people reports them?
I've changed it from eerror to elog now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=542907e8e21b3a2a155d31095b63a1821354c1c7
And why not "einfo"? What is the purpose to get it logged for standard users? Should they report that kind of problems?
I think elog is better, because this means you've got some possibly obsolete symlink's lying around that you may want to do something about. For example, see the skype example in bug 421165. In that case, a message like this could indicate that skype is installed in /opt/skype only due an obsolete /usr/share/skype -> /opt/skype symlink that you wouldn't have in a fresh install.
The problem is that current message doesn't provide any hint about what administrators should check and do and, then, it's possible that this message converts on another one that ends being finally ignore by most people. Not sure how could be updated, maybe adding more information to the message if we really want administrators to manually handle this kind of problem
(In reply to comment #8) > The problem is that current message doesn't provide any hint about what > administrators should check and do Yeah, we could include some suggestions there. > and, then, it's possible that this > message converts on another one that ends being finally ignore by most > people. In practice, I think this message will be relatively rare, so we don't have to worry about to being a source of "information overload" for users. > Not sure how could be updated, maybe adding more information to the > message if we really want administrators to manually handle this kind of > problem Maybe something like this: This indicates that the mentioned symlink(s) may be obsolete remnants of an old install, and it may be appropriate to replace a given symlink with the directory that it points to.
Looks fine to me, but will confirm next time I see that message as looks like after whitelisting /lib and /usr/lib it's, effectively, rare :)
I've add that info to the message: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=324bf88228b7be64814e99dd96ad73a204a5df63
It still happens with 2.1.11.3: * One or more symlinks to directories have been preserved in order to * ensure that files installed via these symlinks remain accessible. This * indicates that the mentioned symlink(s) may be obsolete remnants of an * old install, and it may be appropriate to replace a given symlink with * the directory that it points to. * * /usr/lib64 ls -l / ls -l /usr ... drwxr-xr-x 12 markus users 8192 Jun 27 17:23 lib lrwxrwxrwx 1 root root 3 Oct 10 2011 lib64 -> lib ...
(In reply to comment #12) > lrwxrwxrwx 1 root root 3 Oct 10 2011 lib64 -> lib The problem is that your symlink is backwards. This should fix it: for x in / /usr/ ; do rm ${x}lib64 && mv ${x}lib ${x}lib64 && ln -s lib64 ${x}lib ; done Note that the plan is to migrate away from symlinks, as mentioned here: http://archives.gentoo.org/gentoo-dev/msg_e556ce7187d8f80e7d4e46999db61d7b.xml
(In reply to comment #13) > (In reply to comment #12) > > lrwxrwxrwx 1 root root 3 Oct 10 2011 lib64 -> lib > > The problem is that your symlink is backwards. This should fix it: > > for x in / /usr/ ; do rm ${x}lib64 && mv ${x}lib ${x}lib64 && ln -s lib64 > ${x}lib ; done (This will fail after the first "rm /lib64" on a live system...)
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > lrwxrwxrwx 1 root root 3 Oct 10 2011 lib64 -> lib > > > > The problem is that your symlink is backwards. This should fix it: > > > > for x in / /usr/ ; do rm ${x}lib64 && mv ${x}lib ${x}lib64 && ln -s lib64 > > ${x}lib ; done > > (This will fail after the first "rm /lib64" on a live system...) So, install busybox with USE=static and then run 'busybox ash' to get a static shell to run the command from.
You can also disable the warning for /usr/lib64 by setting the following in make.conf: UNINSTALL_IGNORE="${UNINSTALL_IGNORE} /usr/lib64"
