Archive:PackagingDrafts/Absolute symlinks in fonts templates (2009-01-02)

Introduction
Sarantis Paskalis noticed the new font templates use absolute symlinks for fontconfig files which triggers an rpmlint warning. He then proceeded to locate the upstream rpmlint discussion that led to the addition of this check.

Note that even though the title of this draft says “fonts templates”, the relative vs absolute symlinks issue is not at all specific to font packages, but a generic packaging consideration that could deserve a packaging guideline.

Discussion

 * 1) The main value of “always relative symlinks” is that doing so results in least surprises when working inside chroots.  The value of chroots can nowadays be argued to be less than it used to be due to VM technology improvements.
 * 2) When constructing relative symlinks between paths that contain rpm macro variables in specfiles, more care is required than is generally perceived (no assumptions should be made about what the macros expand to).
 * 3) Relative symlinks may break or behave unexpectedly when a part of a filesystem is mounted to a custom location.
 * 4) One safe way to create relative symlinks is the little used and little known symlinks command. But rpmlint won't tell people this. (Update: upstream development version of rpmlint does.)

Three suggested options for FPC to choose from:

Option 1: Do not care
Do not care at all whether symlinks are absolute or relative. No changes to guidelines are needed, and the related warnings should be disabled in the Fedora rpmlint package's default config.

Option 2: Always prefer relative symlinks

 * 1) Generalise the use of symlinks instead of ln in our spec files and templates, and document it in our guidelines.
 * 2) No changes needed to rpmlint (use of symlinks(8) is already documented in upstream development version which will eventually be shipped in Fedora).

Option 3: Prefer relative symlinks within top level dir tree, absolute between top level trees
This approach tries to capture the best properties of options 1 and 2. It is what Debian does: http://www.debian.org/doc/debian-policy/ch-files.html#s10.5 http://lintian.debian.org/tags/symlink-should-be-relative.html


 * 1) Generalise the use of symlinks instead of ln in our spec files and templates, and document it in our guidelines.
 * 2) rpmlint can be configured to check this policy.