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

Revision as of 19:18, 3 January 2009

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

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 due to VM technology improvements.
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).
Relative symlinks may break or behave unexpectedly when a part of a filesystem is mounted to a custom location.
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

Generalise the use of symlinks instead of ln in our spec files and templates, and document it in our guidelines.
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

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

Fonts in Fedora
The Fonts SIG takes loving care of Fedora fonts. Please join this special interest group if you are interested in creating, improving, packaging, or just suggesting a font. Any help will be appreciated.

@@ Line 5: / Line 5: @@
 Sarantis Paskalis [http://www.redhat.com/archives/fedora-fonts-list/2008-December/msg00026.html noticed] the new font templates use absolute symlinks for fontconfig files which triggers an ''rpmlint'' warning. He then proceeded to locate the upstream rpmlint [http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/25 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.
+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 ==
-# The value of the check is dubious, chroots present many problems and nowadays vms are a lot safer.
+# 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 due to VM technology improvements.
-# The rpmlint check does not tell packagers at all how to safely create relative symlinks. A package will almost always put files in directories defined by rpm macros that are supposed to expand to anything, a packager will create relative symlinks by positing some fixed value for those macros.
+# 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).
-# The safe way to create relative symlinks is the little used and little known ''symlinks'' command. But rpmlint won't tell people this.
+# Relative symlinks may break or behave unexpectedly when a part of a filesystem is mounted to a custom location.
+# 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.)
-So we have a warning that addresses an obscure corner case already broken in many ways, that will induce packagers to write spec files broken WRT rpm macros, with the correct solution not documented anywhere. There are two possible options for [[FPC]] to choose:
+Three suggested options for [[FPC]] to choose from:
-== Option 1: remove the warning ==
+== Option 1: Do not care ==
-Ask our rpmlint packager to disable the warning in Fedora, since it's more pain that it's worth.
+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: change our guidelines ==
+== Option 2: Always prefer relative symlinks ==
-# Make the ''rpmlint'' check an actual Fedora packaging guideline.
+# Generalise the use of ''symlinks'' instead of ''ln'' in our spec files and templates, and document it in our guidelines.
-# Generalise the use of ''symlinks'' instead of ''ln'' in our spec files, and document it in our guidelines.
+# No changes needed to ''rpmlint'' (use of symlinks(8) is already documented in upstream development version which will eventually be shipped in Fedora).
-# Ask our rpmlint packager to make the warning a little more obvious (as in, stating the command people are actually supposed to use)
-# Change the font templates to use ''symlinks'' like the rest of the distro.
+== 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
+# Generalise the use of ''symlinks'' instead of ''ln'' in our spec files and templates, and document it in our guidelines.
+# ''rpmlint'' can be configured to check this policy.
 {{:Fonts_SIG_signature}}[[Category:Fonts packaging guideline change proposals|2009-01-02, Symlinks, relative]]

Search