OK, so now portage will make an attempt to keep symlinks, apparently related to bug #326685 comment #18. Quoting the message text, so users will find this bug: ERROR: postrm One or more symlinks to directories have been preserved in order to ensure that files installed via these symlinks remain accessible: /some/path/to/a/symlink_to_dir I got a number of elog mails due to this, and all of them bogus so far: 1. Unmerged all of KDE3 from kde-sunset. Most packages had a symlink called /usr/kde/3.5/share/doc/HTML/en/${PN}/common pointing to some common KDE docs. 2. Unmerged kde-base/okteta which had a symlink called /usr/share/doc/HTML/en/okteta/common looking very much like the KDE3 setup. 'ls -1d /usr/share/doc/HTML/en/*/common | wc -l' counts 116 such links. 3. /usr/share/doc/boost-1.46.1/html/boost when upgrading dev-libs/boost using portage-2.2.0_alpha51. Not sure whether that was before or after 40f45506b5. I'm not exactly sure how to improove this, but I believe that the current code leads to way too many false alarms. Perhaps the best thing to do would be checking whether any other package was installed using that symlink, and if not, remove the link anyway. I know this might be a costly operation, but it should be rather rare, right? Perhaps the result should be cached somehow, as e.g. large KDE unmerges would check for the same target dir over and over again. Another way would be for an ebuild to actually declare a symlink as being "foreign", i.e. pointing to code outside its sphere of control. Which might again lead to packages installed using those symlinks if used incorrectly.
(In reply to comment #0) > Perhaps the best thing to do would be > checking whether any other package was installed using that symlink, and if > not, remove the link anyway. I know this might be a costly operation, but it > should be rather rare, right? Yes, we can do that. Even without a cache, it should be rare enough that the performance penalty is not a major obstacle. > Perhaps the result should be cached somehow, as > e.g. large KDE unmerges would check for the same target dir over and over > again. We have an owners cache that hashes files by basename, but it performs very poorly for basenames that are not very unique. The reason that it uses the basename is that the basename serves as a reliable hash even in cases where the parent directories happen to be symlinks. For example, if a file with basename 'x' is installed as /usr/lib/x and /usr/lib is a symlink to /usr/lib64, the hash of the basename 'x' is constant regardless of whether CONTENTS entry refers to it via /usr/lib or /usr/lib64.
Hit this again today, including boost. Any progress yet?
Same issue is in libreoffice. It would be cool to see this fixed :)
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=411a8461d08b88c5636e900d6297c2b4873af549
This is fixed in 2.1.10.49 and 2.2.0_alpha89.
is there any switch to disable the 'happy removing things that might not be used by something else' behavior? or even better a non-default switch to enable that? because: 1. not all software present on a gentoo box is guaranteed to reside in portage or even in an overlay. think closed source third-party non-publicly available montly-changing software. (yes that's a real scenario). making an ebuild for something like this is a waste of time. I place that into /local with a symlink from /opt. /opt will be removed by portage. that software will start breaking with nasty implications. 2. gentoo is by definition infinitely-customizable. I have one /tmp mounted as tmpfs and /var a smallish partion with /var/tmp a symlink to /tmp. that /var/tmp symlink will be removed by portage since it is falsely believed not to be in use. software using /var/tmp will of course go dead. these two scenarios are just what I found in an hour, there might be other non-obvious ones. there is nothing worse than software that tries to be too smart for it's own good.
This bug here was about packages not removing symlinks they created themselves. The fix was to enable said removal if no one else was using those symlinks. If you have any issues about packages or portage in general removing symlinks which you as an admin added manually, then this seems like a different issue that would be better tracked in a separate report.
the code commited to fix your original bug has the unfortunate side-effect of removing symlinks I'm attached to. unfortunately I can't reopen the bug :/
(In reply to comment #6) > is there any switch to disable the 'happy removing things that might not be > used by something else' behavior? or even better a non-default switch to > enable that? You can use a setting in make.conf like this: UNINSTALL_IGNORE="${UNINSTALL_IGNORE} /path/of/protected/symlink"
