Fontconfig rules installation guidelines change proposal

[Nicolas Mailhot]

Hi all,

I've queued the following small guideline change proposal for FPC
consideration:

http://fedoraproject.org/wiki/PackagingDrafts/Fonts_spec_template_correction...)

Please add comments, reactions and corrections in the wiki.

Regards,

[Behdad Esfahbod]

Nicolas Mailhot wrote:
> Hi all,
>
> I've queued the following small guideline change proposal for FPC
> consideration:
>
> http://fedoraproject.org/wiki/PackagingDrafts/Fonts_spec_template_correction...)
>
> Please add comments, reactions and corrections in the wiki.

Hi Nicolas,

I like the direction of it.

The idea of having separate conf.avail and conf.d is that sysadmins can
symlink/unlink entries into conf.d to enable/disable configuration for their
system.  This would only work if upgrading fontconfig/fonts rpms does not
reinstate the unlinked symlink.  However, last time I checked this was not
working correctly.  Can you check this first?

Thanks,

behdad
> Regards,

[Nicolas Mailhot]

Le mercredi 15 octobre 2008 à 15:10 -0400, Behdad Esfahbod a écrit :

conf.avail and conf.dyyyyyyyyyyyyyyy
> Hi Nicolas,

Hi Behdad,

Thank you for reviewing it,
> I like the direction of it.
>
> The idea of having separate conf.avail and conf.d is that sysadmins can
> symlink/unlink entries into conf.d to enable/disable configuration for their
> system.  This would only work if upgrading fontconfig/fonts rpms does not
> reinstate the unlinked symlink.  However, last time I checked this was not
> working correctly.  Can you check this first?

I didn't write it in the wiki, but as far as I understand rpm it is not
possible to tell it "if this file/symlink does not exist do not install
it". So this bit of conf.avail/conf.d design will never work on rpm
systems. And even if it worked, what you'd actually need would be "if
this file does not exist and was installed by a previous rpm" to handle
initial deployment. Which starts to be real hairy. (more generally
treating absence of an item as disabling this item is a broken computer
pattern IMHO.)

However (someone please check this) it's probably possible to disable an
entry permanently by creating a symlink with the same name pointing
somewhere else (how does fontconfig reacts to /dev/null symlinks or
symlinks pointing to empty files)? So having a repository of
pre-deployed config snippets is fine with me.

Also (and this bit is traced on the wiki) as I understand the
FHS /etc/.../conf.avail is a complete no-go and should be moved
to /usr/share/something if we want to be clean. And that
before /etc/.../conf.avail is duplicated in many packages.

[Behdad Esfahbod]

Nicolas Mailhot wrote:
> Le mercredi 15 octobre 2008 à 15:10 -0400, Behdad Esfahbod a écrit :
> > Hi Nicolas,
>
> Hi Behdad,
>
> Thank you for reviewing it,
> > I like the direction of it.
> >
> > The idea of having separate conf.avail and conf.d is that sysadmins can
> > symlink/unlink entries into conf.d to enable/disable configuration for their
> > system.  This would only work if upgrading fontconfig/fonts rpms does not
> > reinstate the unlinked symlink.  However, last time I checked this was not
> > working correctly.  Can you check this first?
>
> I didn't write it in the wiki, but as far as I understand rpm it is not
> possible to tell it "if this file/symlink does not exist do not install
> it". So this bit of conf.avail/conf.d design will never work on rpm
> systems. And even if it worked, what you'd actually need would be "if
> this file does not exist and was installed by a previous rpm" to handle
> initial deployment. Which starts to be real hairy.

Well, it is: don't include the symlink in the RPM but create it in %post, and
only if no previous versions of the package were installed ($1 = 0 IIRC).
> (more generally
> treating absence of an item as disabling this item is a broken computer
> pattern IMHO.)

The alternative would be people editing the files to disable them.  Not much
more package-manager friendly.
> However (someone please check this) it's probably possible to disable an
> entry permanently by creating a symlink with the same name pointing
> somewhere else

This can be ok.  If it works, we can document it.
> (how does fontconfig reacts to /dev/null symlinks or
> symlinks pointing to empty files)?

Works fine.
> So having a repository of
> pre-deployed config snippets is fine with me.
>
> Also (and this bit is traced on the wiki) as I understand the
> FHS /etc/.../conf.avail is a complete no-go and should be moved
> to /usr/share/something if we want to be clean. And that
> before /etc/.../conf.avail is duplicated in many packages.

Really?  Where does it talk about those kind of stuff?

behdad

[Nicolas Mailhot]

Le Mer 15 octobre 2008 22:39, Behdad Esfahbod a écrit :
> Nicolas Mailhot wrote:
> > Le mercredi 15 octobre 2008 à 15:10 -0400, Behdad Esfahbod a écrit :
> > > The idea of having separate conf.avail and conf.d is that sysadmins
> > > can
> > > symlink/unlink entries into conf.d to enable/disable configuration
> > > for their
> > > system.  This would only work if upgrading fontconfig/fonts rpms
> > > does not
> > > reinstate the unlinked symlink.  However, last time I checked this
> > > was not
> > > working correctly.  Can you check this first?
> >
> > I didn't write it in the wiki, but as far as I understand rpm it is
> > not
> > possible to tell it "if this file/symlink does not exist do not
> > install
> > it". So this bit of conf.avail/conf.d design will never work on rpm
> > systems. And even if it worked, what you'd actually need would be
> > "if
> > this file does not exist and was installed by a previous rpm" to
> > handle
> > initial deployment. Which starts to be real hairy.
>
> Well, it is: don't include the symlink in the RPM but create it in
> %post, and
> only if no previous versions of the package were installed ($1 = 0
> IIRC).

Yurk. How safe is it WRT package renames? Because we've been renaming
font packages a lot in the past (and I plan another mass rename for
F11, hopefully the last one but I wouldn't bet anything I care about
on it).

Really this is being too clever for your own good IMHO.
> > However (someone please check this) it's probably possible to
> > disable an
> > entry permanently by creating a symlink with the same name pointing
> > somewhere else
>
> This can be ok.  If it works, we can document it.
> > Also (and this bit is traced on the wiki) as I understand the
> > FHS /etc/.../conf.avail is a complete no-go and should be moved
> > to /usr/share/something if we want to be clean. And that
> > before /etc/.../conf.avail is duplicated in many packages.
>
> Really?  Where does it talk about those kind of stuff?

In conf.avail files are not really user-editable config files (in fact
you don't use config(noreplace) so any package update will stomp on
user modifications). They're more static configuration blocks users
can not change but only activate/desactivate in conf.d via symlinks,
and as such they match the "read-only architecture independent data
files" definition of /usr/share.

That rpmlint complains of %config files without noreplace in /etc is a
pretty strong hint those files are misplaced. In fact one can wonder
what's good is there %config-ing them at all.

IIRC there was a pretty long thread on the subject in fedora-devel in
the last months, but I don't have the time to pull it from archives.