Policy 10.5 (Symbolic links) currently has two classes of requirements:

Symlinks between /${x} and /${x} (same top-level directory) must use
relative links; symlinks between /${x} and /${y} (different top-level
directories).

The historic reasons[1][2] point out this is to allow /usr (or other
top-level directories) to be a symlink to somewhere else which would
break symlinks using '..' in their target.

It seems strange to treat top-level directories differently: why
should /usr be allowed to be a symlink, but /usr/local, /usr/lib or
/usr/share/doc not?  I can't come up with a better idea than that
top-level directories are something like "driver letters".

So I suggest to either:

(a) require *all* symlinks to be relative
(b) forbid using '..' in symlinks

(a) would imply that users would have to use bind-mounts instead of
symlinks; (b) would allow any directory to be a symlink, but require
tools acting on chroots to be aware of symlinks (but they have to be
that already as we sometimes require absolute symlinks already).

Ansgar

  [1] https://lists.debian.org/debian-policy/1998/04/msg00110.html
  [2] https://lists.debian.org/debian-policy/1998/03/msg00050.html

You target directories, but don't mention files in your wording, and I
think forbidding use of '..' in symlinks unilaterally is the wrong
approach, for this simple reason:

steven@wrecked:~% find /usr/share/doc -type l -exec ls -l "{}" \; | grep
-c '\.\./.*Debian.gz'
746

If the wording  was ratcheted down to forbidding '..' for symlinking
directories, I think I'm okay with it.

Cheers,

Ansgar Burchardt <ansgar@debian.org> writes:

I think the rationale was just that it was more common to move top-level
directories to another drive with more space than it was to muck about
below the top level.  I'm not sure we document that difference anywhere
useful for the user, though.

Personally, I prefer (b) -- I think relative symlinks that ascend out of a
directory are a questionable pattern in general.  But this is a very large
change that would affect a lot of packages (admittedly, in a way that
could mostly be cleaned up by debhelper), and is also a pretty significant
break with past practice that will probably break some system out there in
some way.

Dear Maintainer,

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039979 has come up as something to consider regarding this related change in debian policy.

In that context, I'd advocate for permitting '..' in symlinks, even if only as an exception for those specific paths to enable safer working with chroots.