Bug 565895

Summary:	unfortunate symlink /etc/fonts/conf.d/57-dejavu-sans.conf -> /usr/share/fontconfig/...
Product:	[Fedora] Fedora	Reporter:	John Reiser <jreiser>
Component:	dejavu-fonts	Assignee:	Nicolas Mailhot <nicolas.mailhot>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	fonts-bugs, nicolas.mailhot
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-02-16 19:07:51 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description John Reiser 2010-02-16 16:35:12 UTC

Description of problem:  A symbolic link with an absolute (rooted) target:
  /etc/fonts/conf.d/57-dejavu-sans.conf -> /usr/share/fontconfig/conf.avail/57-dejavu-sans.conf
creates some problems for the Fedora installer (anaconda).  Because the target of the symlink is rooted instead of relative, then the link is difficult to virtualize when creating the install.img filesystem that the installer uses, and it is problematic whether the symlink actually will work during install.  It would be easier to have a relative symlink such as
   /etc/fonts/conf.d/57-dejavu-sans.conf -> ../../../usr/share/fontconfig/conf.avail/57-dejavu-sans.conf

An example of an existing relative symlink is
   /etc/fonts/conf.d/20-fix-globaladvance.conf -> ../conf.avail/20-fix-globaladvance.conf

A similar problem occurs for:
  20-unhint-small-dejavu-sans.conf
  20-unhint-small-dejavu-sans-mono.conf
  25-ttf-arphic-uming-render.conf
  35-ttf-arphic-uming-aliases.conf
  41-ttf-arphic-uming.conf
  57-dejavu-sans-mono.conf
  64-ttf-arphic-uming.conf
  65-un-core-dotumbold.conf
  65-un-core-dotum.conf
  66-lohit-assamese.conf
  66-lohit-bengali.conf
  66-lohit-devanagari.conf
  66-lohit-gujarati.conf
  66-lohit-kannada.conf
  66-lohit-oriya.conf
  66-lohit-punjabi.conf
  66-lohit-tamil.conf
  66-lohit-telugu.conf
  66-smc-meera.conf
  66-vlgothic-gothic.conf
  90-smc-fonts.conf
  90-ttf-arphic-uming-embolden.conf


Version-Release number of selected component (if applicable):
dejavu-sans-fonts-2.30-2.fc12.noarch


How reproducible: every time


Steps to Reproduce:
1. ls -l /etc/fonts/conf.d/57-dejavu-sans.conf
2.
3.
  
Actual results:
/etc/fonts/conf.d/57-dejavu-sans.conf -> /usr/share/fontconfig/conf.avail/57-dejavu-sans.conf


Expected results:
/etc/fonts/conf.d/57-dejavu-sans.conf -> ../../../usr/share/fontconfig/conf.avail/57-dejavu-sans.conf


Additional info:

Comment 1 Nicolas Mailhot 2010-02-16 19:07:51 UTC

The question of symlinks has been debated to death by FPC in the past and no one has found a compelling argument for or against absolute/relative symlinks. They work better in some situations, and worse in others. In the end it was decided not to mandate one form or the other (and disable the rpmlint check that tried to force one of the choices)

In the fonts case absolute symlinks make the spec template simpler, which is a clear maintenance benefit, so the official Fedora fonts spec template uses absolute symlinks.

I don't intend to change it unless rpm makes it as easy to use relative symlinks, or someone manages to convince FPC/FESCO they are clearly better and should be mandated.

It is known some use cases are not absolute-symlinks-proof. However others are not relative-symlinks-proof. So you're not finding anything new.

IMHO since Fedora intentionally does not mandate a specific symlink form, if you can't handle both of them, you're going to have trouble sooner or later.