Jason Stubbs posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 24 Dec 2005 02:22:06 +0900:
> A quick patch makes symlinks handled similarly to regular files and > solves the issue. I'll put it into testing unless anybody can come up > with a reason not to. The case that will be broken by the patch is when > two different packages install the same symlink. PackageA is > installed, PackageB is installed, PackageB is uninstalled -> PackageA is > broken. Does this case exist? Yikes! That's not going to remove /lib or /usr/lib or the like, for us on amd64, where that's a symlink to lib64, will it? equery b /lib [ Searching for file(s) /lib in *... ] net-analyzer/macchanger-1.5.0-r1 (/lib) sys-apps/baselayout-1.12.0_pre12 (/lib) sys-boot/grub-0.97 (/lib) sys-devel/gcc-4.0.2-r1 (/lib) sys-devel/gcc-3.4.4-r1 (/lib) sys-fs/device-mapper-1.01.05 (/lib) sys-fs/lvm2-2.01.14 (/lib) sys-fs/udev-078 (/lib) sys-libs/glibc-2.3.6 (/lib) There's a similar, longer list, for /usr/lib. Obviously, not all of those will own it as a symlink, but it is one, and if removing one happens to remove the symlink... Also consider the effect where a former dir is now a symlink or a former symlink is now a dir. The recent xorg directory moves come to mind. You are /sure/ the new code won't screw anything of that sort up, right? Maybe that's the reason nobody seems to have been around to know about. It just sounds like it /could/ be dangerous to me. For some reason, I don't like the idea of something that could hose a system that badly! =8^\ -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
