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

Roger Leigh rleigh at codelibre.net
Wed May 11 10:04:06 UTC 2011


On Wed, May 11, 2011 at 10:12:06AM +0200, Bill Allombert wrote:
> On Tue, May 10, 2011 at 03:32:24PM -0700, Russ Allbery wrote:
> > Carsten Hey <carsten at debian.org> writes:
> > 
> > > 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.
> > 
> > Is there any reason *not* to continue supporting them?  They can
> > definitely save you as a short term measure to work around a bad
> > partitioning scheme until one can fix it by reformatting.
> 
> A reason might be that now we have bind mounts which are generally much more
> robust than symlinks. That was not the case where this policy was written.

Thanks everyone for your explanations.  I've updated the symlinks to
be absolute.

I am, however, unsure if the policy is the ideal solution today
compared with 1998 when the Linux VFS was much more primitive.
I am yet to be convinced that the absolute link is better technically.
One thing I'm wanting to do (when time allows) is work on merging
/usr and / where /usr would become a symlink to /.  That link would
be "/" or ".." and having it absolute would not be good if you look
up the path /chroot/usr/bin/foo since you'll actually get /bin/foo
on the host, where the path might not even be valid (it might be
/usr/bin/foo).  With a relative link it will always work correctly.
This is exactly the same issue as the /var/run symlink.

Other than the rather special use case for absolute links for top level
dirs, I'm not sure that absolute links are preferable to relative.
Although chroot environments are a special case, absolute symlinks in
the chroot could cause serious problems on the host if a link in the
chroot points to somewhere on the host; you might end up using the wrong
programs, libraries, or even blowing away a huge chunk of the host's
filesystem.


I guess from the policy POV this is concerns what we consider to be
acceptable practice for a sysadmin.  While the policy caters for
admins who create symlinks for top-level directories, this practice
does not extend to subdirectories--where things would still break.
Symlinks can be fragile, and we have much better means to rearrange
the filesystem now--and this applies to all the platforms we support,
not just Linux.

From the POV of packaging, I'd like symlinks to point to a specific
place, without ambiguity, and in the context of chroots, a relative
link is unambiguous whereas an absolute link changes depending on
where we are rooted.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20110511/d85861af/attachment.pgp>


More information about the Pkg-sysvinit-devel mailing list