The FHS mandates that some files installed by fontconfig should probably not be installed where they are now (for example, the configuration snippets should *not* be modified by users, they should unlink the one they want to change and edit a copy as a new file, to prevent problems on fontconfig package upgrades)
Make the associated paths configurable, and set sane default values
(see attached patch)
Paths use the same conventions already in place for a few releases in Fedora font packages
Moving the dtd is more cosmetic, but is nice when a distro uses xmlcatalog (as Fedora does)
Created attachment 37500 [details] [review]
Patch to make those changes, lightly tested inside an rpm build environement
Please provide your feedback for attached patch. If looks ok then can you please commit it upstream so that I can use it in Fedora fontconfig build?
The confdir vs masterconfdir distinction looks like an overkill to me. Why do you need both?
(In reply to comment #4)
> The confdir vs masterconfdir distinction looks like an overkill to me. Why do
> you need both?
That's mainly historical, I didn't want to be too invasive and move /etc/fonts/fonts.conf (no idea how many places this part is hardcoded into).
Unless you want to prohibit users changing fonts.conf, and force them to make all their changes in detached /etc/fonts/conf.d files, you need to keep a directory in /etc to put it in
Granted, if FHS support had been built in fontconfig from the start, and not retrofited now, the directory structure would probably have looked more like :
/usr/share/xml/fontconfig/ ← dtd and other schema files, /usr/share/xml/fontconfig.dtd if we're sure there will only be one dtd file forever
/usr/share/fontconfig/ ← configuration snippets, templates, etc
/etc/fontconfig.conf ← master configuration file
I tried to limit changes to the strict minimum to be FHS compliant and silence rpm warnings
That's the same structure as we have right now, more or less...
I need more time processing this then. I still think it can be done in a simpler way.
What's the required features you want to see? Being able to move templates to /usr/share is one. What else? Do you want other packages to be able to query the conf.d dir?
(In reply to comment #6)
> What's the required features you want to see? Being able to move templates to
> /usr/share is one. What else? Do you want other packages to be able to query
> the conf.d dir?
I want to :
1. move the schema files to /usr/share/xml to be able to register them in the system catalog files cleanly so xml tools just as xmllint just work
2. move the detached configuration snippets somewhere in /usr/share/fontconfig to make clear they should not be modified by users
3. reserve a subdirectory in /usr/share/fontconfig where Fedora and other distributions can drop their own configuration templates
(such as the ones in http://git.fedorahosted.org/git/?p=fontpackages.git;a=tree;f=fontconfig-templates)
4. have a specific place in /etc where active configuration files can be dropped or symlinked to
5. have 2. 3. 4. locations configurable at ./configure time so Fedora can pass its locations to fontconfig nad be sure font packages and fontconfig agree where files are (basically, we define font-related locations in http://git.fedorahosted.org/git/?p=fontpackages.git;a=blob_plain and have all font-related packages use those variable to decide where they put stuff)
6. be able to invoque fontconfig utilities such as fc-scan with a directory containing additionnal configuration files (or be able to pass a list of absolute paths of additionnal configuration files), to ask questions such as "what would be the font name associated with this ttf file if you consider the system font configuration and those configuration files I intend to install with the ttf file?
I basically agree with this idea. we should avoid keeping files in /etc at least which isn't desired to be modified by the users.
the proposed fix:
the default path for conf.avail only is changed. others are compatible with the older releases. this should less affects.
fixed in e181ab4d
*** Bug 18470 has been marked as a duplicate of this bug. ***