Absolute vs relative symlinks

[scop]

symlink-should-be-relative is currently missing a description, see  https://bugzilla.redhat.com/196008

Debian's lintian and policy manual put it this way:  http://lintian.debian.org/reports/Tsymlink-should-be-relative.html  http://www.debian.org/doc/debian-policy/ch-files.html#s10.5

I was about to copy-paste the Debian description for the message, but then started to wonder: what are the benefits of absolute symlinks over relative ones in the first place? And why is the line drawn at whether the link points to another top-level dir or not?

The only slight benefit for absolute symlinks I can see is that they may be a bit easier for humans to read eg. in "ls -l" outputs if the link is deep in the dir hierarchy. But that is IMO easily trumped by possible dangers of absolute symlinks for example when operating on chroot jails from the outside.

What am I missing? If nothing, I'd suggest making rpmlint always want relative symlinks, no matter where they point, and dropping the symlink-should-be-absolute check and message altogether.

[Paul Howarth <paul@…>]

I'd vote for relative symlinks everywhere, for the same reasons as you.

It's not as if they're hard to set up, particularly if you use  symlinks:

%install
...
ln -s %{buildroot}/path/to/target %{buildroot}/path/to/source
...
cd %{buildroot}
symlinks -cs .
cd -

[scop]

Ah, "symlinks" is nifty. Another recipe, although somewhat harder to use but then again more flexible is eg. using perl, for example:

...
BuildRequires: perl(File::Spec)
...
%install
...
abs2rel() { perl -MFile::Spec -e 'print File::Spec->abs2rel(@ARGV)' "$@" ; }
for file in $(find $RPM_BUILD_ROOT -type l) ; do
  f=$(readlink $file) ; d=$(dirname ${file#$RPM_BUILD_ROOT})
  case "$f" in /*) rm -f $file ; ln -s $(abs2rel $f $d) $file ;; esac
done
...

[misc]

Having two checks that contradict themself is quite misleading indeed.

So either we drop the two checks, and decide that both are acceptable, or we drop one of them. Relative symlink are usually used for binary, and I think using absolute symlink for /etc is cleaner, I suggest to drop the two checks.

[scop]

I don't remember see any patterns in what usually gets linked relative/absolute. Why/how are absolute symlinks for /etc cleaner, and why is it different from other dirs?

[misc@…]

That is just a personal opinion, but from a sysadmin point of view, hunting for config in /etc, /usr/local/etc/, /usr/pkg/etc ( *bsd ) is quite error prone. But I realise this is out of scope of the original bug report.

I do not have a strong opinion, so if people prefer to keep only relative symlink, it is ok for me to remove the other check.

[scop]

I agree wrt. the "hunting config" part, but one can use relative symlinks to point to /etc instead of /usr/etc and friends, so I don't see how that is directly related to the issue at hand.

Anyway, this is now fixed in changeset [1207] so that relative symlinks are always preferred by default, and the new UseRelativeSymlinks? config option can be set to 0 to restore the old behaviour.