[Pkg-sysvinit-devel] Bug#626263: Clarification of §10.5 symlink wording needed

[Carsten Hey]

* Russ Allbery [2011-05-10 09:41 -0700]:
> Roger Leigh <rleigh at codelibre.net> writes:
>
> > Section 10.5 states:
>
> >      In general, symbolic links within a top-level directory should be
> >      relative, and symbolic links pointing from one top-level directory
> >      into another should be absolute.  (A top-level directory is a
> >      sub-directory of the root directory `/'.)
>
> ...
>
> > This is related to #626263.
> > With the creation of /run we are making /var/run a symlink to /run
> > (and /var/lock a symlink to /run/lock).  The question is whether
> > these links should be absolute or relative.  i.e. should /var/run
> > point to /run or ../run?
>
> It should be absolute: /var is a different top-level directory than /run.

I don't think the policy handles this specific case.  This symlink is
neither _within_ a top-level directory nor points _into_ one.  There are
other symlinks that do not fit into any of these two groups, e.g.,
"lib64 -> /lib/" and "initrd.img -> boot/...".  Anyway, I'm neither
a native speaker, nor do I think the policy should be read this way,
instead the original intention should be considered.

As discussed in a subthread[1] on -devel from 1998 (before LVM or
bind-mounts existed on Linux) some people partly used symlinks to
directories instead of real directories as top-level directories.  With
such a setup, a relative symlink "/var/run -> ../run" could point to
/mnt/foo/run instead of /run.  Since symlinks as top-level directories
apparently have been supported, symlinks out of an top-level directory
needed to be absolute.  Somewhat similar is "/usr -> /", but contrary to
the above, there would not be a problem with relative links because
"/../" is the same real directory as "/".

Besides "/usr -> /", are symlinks to directories still supported as
top-level directories and are there still people using such a setup?
If nobody uses this anymore, the policy could be adapted to the year
2011.


Regards
Carsten

 [1] http://lists.debian.org/debian-devel/1998/02/msg00590.html