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

Revision as of 18:40, 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.

Discussion

The value of the check is dubious, chroots present many problems and nowadays vms are a lot safer.
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.
The safe way to create relative symlinks is the little used and little known symlinks command. But rpmlint won't tell people this.

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:

Option 1: remove the warning

Ask our rpmlint packager to disable the warning in Fedora, since it's more pain that it's worth.

Option 2: change our guidelines

Make the rpmlint check an actual Fedora packaging guideline.
Generalise the use of symlinks instead of ln in our spec files, and document it in our guidelines.
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.

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 that could deserve a packaging guideline.
+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.
 == 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 be due to VM technology improvements.
+# The value of the check is dubious, chroots present many problems and nowadays vms are a lot safer.
-# 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 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.
-# Relative symlinks may break or behave unexpectedly when a part of a filesystem is mounted to a custom location.
+# The safe way to create relative symlinks is the little used and little known ''symlinks'' command. But rpmlint won't tell people this.
-# 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:
+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:
-== Option 1: Do not care ==
+== Option 1: remove the warning ==
-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.
+Ask our rpmlint packager to disable the warning in Fedora, since it's more pain that it's worth.
-== Option 2: Always prefer relative symlinks ==
+== Option 2: change our guidelines ==
-# Generalise the use of ''symlinks'' instead of ''ln'' in our spec files and templates, and document it in our guidelines.
+# Make the ''rpmlint'' check an actual Fedora packaging guideline.
-# No changes needed to ''rpmlint'' (use of symlinks(8) is already documented in upstream development version which will eventually be shipped in Fedora).
+# Generalise the use of ''symlinks'' instead of ''ln'' in our spec files, and document it in our guidelines.
+# Ask our rpmlint packager to make the warning a little more obvious (as in, stating the command people are actually supposed to use)
-== Option 3: Prefer relative symlinks within top level dir tree, absolute between top level trees ==
+# Change the font templates to use ''symlinks'' like the rest of the distro.
-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