[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#632682: we should probably remove /lib64 -> lib symlink (with care)



On Thu, Aug 18, 2011 at 09:00:52AM +0200, Sven Joachim wrote:
> > The right way to handle it is to create the directory under a separate
> > name, populate the symlink, and only *then* rm /lib64 and invoke mv
> > /lib64.real /lib64 via $interpreter.  This minimizes the window when /lib64
> > is missing, and just happens to also remove the inode problem as a side
> > effect (because we create all the directory entries we need before we remove
> > any).

> Yes, that's better.  Instead of hardcoding /lib64.real the directory
> should be created with mktemp -d (I think that's what you meant to do).

Hmm, no, I didn't see a need for mktemp here.  You're concerned about a
collision with an admin-created directory?  That seems improbable to me, but
certainly using mkdir doesn't hurt.

> >> Subject: [PATCH 2/6] Install the dynamic linker into RTLDDIR as well as /lib

> >> Installing into both locations makes it easier to support downgrades.
> >> It also means that dpkg will fail to unpack our package if
> >> RTLDDIR=/lib64 and /lib64 is a symlink to /lib.  Which is probably a
> >> good thing since that symlink has to go away.

> > I'm not keen on this.  Why would we want to install a second copy of
> > ld-linux-x86-64.so.2 to /lib?  Nothing will use it there.  Shouldn't we be
> > installing *only* to RTLDDIR, not to both?

> I don't have a strong opinion on this.  Make sure to copy
> ld-linux-x86-64.so.2 to /lib in the prerm on downgrades then; if the
> downgrade fails during unpack, /lib/ld-linux-x86-64.so.2 is unowned.

Sure.

> > And no, this won't cause dpkg to fail to unpack.  dpkg happily traverses
> > symlinks while unpacking and would never notice that the two files are being
> > installed to the same location.

> It does if the files are contained in the same package, an example can
> be found in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624724#10.

I don't think that's an accurate interpretation of what's happening in that
bug, but would need to see the filesystem to say what is happening.  But as
the error is "no such file or directory", it probably means it's managed to
get itself into a situation of trying to unpack a file for which the parent
directory doesn't exist.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature


Reply to: