Bug#230857: Preinst should rename old devpts.sh to mountkernfs
On Mon, 2004-03-15 at 01:01, Miquel van Smoorenburg wrote:
> I'm working on it. To be able to script several parts of this easily,
> maintaining the /run functionality and also dynamic root dev
> functionality for lvm and raid in which I have been involved at
> the kernel level, we need a reliable 'readlink' utility - as Thomas
> might remember, the behaviour of the current readlink has changed
> a few times. I have now found that the cause is a questionable
> implementation of readlink() in glibc, and I'm trying to write
> a reasonable replacement which isn't quite trivial and is holding
> things up for now.
I pursued the readlink() issue with upstream. Most of the
discussion is logged in coreutils bug #225836: "readlink: Please
implement --recursive option".
While discussing this with upstream I came to the view that the
current behavior of readlink() is reasonable. If the target of
a symlink does not exist then it is impossible to say what the
path to "the" ultimate file is. There is no ultimate file.
One could imaging the target of the original symlink being a
file or another symlink and these would have different canonical
paths.
Nevertheless we have a need for a feature which I described in
#225836 this way:
> What I would like it to do (not necessarily in -f mode ...
> perhaps in a new -r mode) is to print A/B where A is the
> longest path portion of FILE that can be canonicalized and
> B is the remaining portion of FILE, verbatim.
I explained the motivation:
> Debian's checkroot.sh initscript wants to delete the mtab backup
> file. This backup file will be stored by the mount program in
> the same directory as the mtab file itself. This directory is
> only known to checkroot.sh and to mount as the parent of the
> ultimate target of /etc/mtab. Now, the mount program has no
> trouble finding out what this directory is because it creates
> the mtab file before asking for its canonical path. However,
> checkroot.sh has to deal with the case where mtab does not
> exist but the backup file does exist. The current "readlink -f"
> is useless for this. However, a "readlink -r" as I described
> it would do the trick. Suppose /etc/mtab is a symlink to
> "mount/mtab". The proposed "readlink -r /etc/mtab" would print
> "/etc/mount/mtab" from which the name of the parent, "/etc/mount"
> could be extracted.
Mike went on to say:
> One thing that's pretty much for sure is that the next sysvinit will
> ship (hopefully monday) with a /lib/init directory with alternatives
> for standard utils or sysvinit-specific helpers that it needs for
> the initscripts package.
Great. I'll look it over when it is released.
--
Thomas Hood <jdthood@yahoo.co.uk>
Reply to: