conf.avail, rpmlint and the FHS

[Nicolas Mailhot]

Hi all,

When conf.avail was introduced in fontconfig we at Fedora mostly ignored
it and let font packages install their fontconfig rules directly in
conf.d
http://fedoraproject.org/wiki/Packaging/FontsSpecTemplate
(the exception being the fontconfig package itself who perforce followed
the new conventions).

Recent events made me revisit this point and try to heal the rift
between fontconfig and font packages by following common conventions.
http://fedoraproject.org/wiki/PackagingDrafts/Fonts_spec_template_correct...

In the course of the examination of this guideline change proposal,
however, it was identified that conf.avail as currently designed causes
our rpmlint package sanity check tool to emit errors. Those errors were
ok for Behdad to ignore, but really not ok for general packaging
guidelines we want to put into newbie packager hands.

The core reason are that since we deploy policy through those fontconfig
files, we absolutely do not want users to change them (they're free to
un-reference the files in conf.d, or write their own fontconfig rules in
different files, but we instruct rpm to stomp on old versions of our
files on updates). Since we mark those files as non-modifiable (%config
and not %config(noreplace) in rpm speak) rpmlint considers them as data,
not configuration, and complains of their location under /etc.

After thinking a bit about it I feel rpmlint is right — since we don't
let users modify our fontconfig files they're not dynamic configuration,
just static data users can choose to activate or not.

We could of course add an exception in rpmlint just for conf.avail, but
I'd rather have fontconfig be fixed to follow more closely the FHS.
Exceptions ultimately pile on till you have a lot of cruft to clean up
which is not my definition of fun.

Can conf.avail and its contents be moved in /usr/share/something in the
next version of fontconfig?

See also:
http://fedoraproject.org/wiki/Packaging/Minutes/20081021

Regards,

-- 
Nicolas Mailhot