On Saturday 24 December 2005 03:43, Duncan wrote:
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...
I'm not familiar with equery so I don't know what this output means. By the
look of it, it is only a list of packages that own stuff in that directory.
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.
With the patch I've done, recorded symlinks will continue to be ignored if the
target is not a symlink.
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^\
*Please* don't tell me you run ~arch.
--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list