For this we need to move the fontconfig cache to /usr.  See https://git.gnome.org/browse/gnome-continuous/tree/manifest.json?id=6d10d44c7f656a2ded923e8c61c4b0c4465a3d10#n170

I notice that this is still a problem. Also in F25 Atomic. I want to install the nvidia binary driver from rpmfusion, and fontconfig is a dependency. Is there a testing version of this package available somewhere built with the cache directory under /usr?

One concern is, that proposed directory, /usr/lib/fontconfig/cache is writable from the POV of SELinux? and possible slowness on updating caches for people who mount /usr through nfs?

RPM scripts are fully privileged and can write to /usr.  And we don't support NFS /usr anymore: https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

Sure. maybe I should open a change proposal for f26 and get more attentions on it.

Unfortunately this proposal isn't compatible with the FHS requirements of /usr, which is supposed to be read only.

.. by "read only" I really mean static rather than dynamically generated. /var/cache really is the right location for this sort of thing.

(In reply to Jonathan Underwood from comment #6)
> Unfortunately this proposal isn't compatible with the FHS requirements

Agree with this. Can't see how /usr could be the right choice.

There's many other derived caches in /usr.  gtk-update-icon-cache is one offhand.
GNU info pages (`install-info`).  kernel modules (depmod -a).

Remember that in the ostree model:
https://ostree.readthedocs.io/en/latest/manual/adapting-existing/
Things like the RPM database are also moved to /usr/share/rpm.

OSTree also *enforces* that /usr is read-only at runtime - but with rpm-ostree, we construct a new tree on the client side, and run %posts there with it mutable, then it's sealed back up at runtime.

An important thing to keep in mind with the FHS is that they tried to push for having /usr be NFS mountable, which Fedora (and all systemd systems), don't support.  It's just not relevant - it's easier to NFS mount /, and do something like ostree on the server to dedup the /usr content between different hosts.

Basically, the FHS requirements are from a previous mindset - the https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ merge pushed the semantics for /usr in a different direction, and OSTree goes much farther with it.

The main concern I have here about breaking things is more around upgrades for people who are using yum/dnf on the host.  I could probably change rpm-ostree to include an e.g. `OSTREE_SEMANTICS=1` environment variable, and the fontconfig %post could key off that.

Rather than thinking of the above things as "caches", they're more like "indexes" or "lookup tables".  The distinction is that they're *only* written or generated during a software installation.

A good example of another one of these to move to /usr would be /etc/ld.so.cache.

Rather than moving the cache around -- or, I guess, in addition to it, but obviating an concern about FHS or dyanamic, unmanaged files in /usr, could we just pregenerate the cache files at _build_ time rather than install time? They appear to be arch specifc (well, word size and order specific) but not really host-specific.

Bonus: faster system install (when not using ostree; I guess faster ostree generation too).

I agree with Colin's assessment that the FHS doesn't really cover this situation well. From the section on /var:

   /var is specified here in order to make it possible to mount /usr
   read-only. Everything that once went into /usr that is written to
   during system operation (as opposed to installation and software
   maintenance) must be in /var.

But here, we're talking about stuff that is written specifically and only during "installation and software maintenance". That's just not well-accounted-for in the spec. Generate-at-build-time as I suggest above might (I hope) work for fontconfig, but it won't for /etc/ld.so.cache -- and I guess that living in /etc may be a reflection of the above problem.

OK, I mostly buy that. But, I think you're arguing that this is data for fontconfig (and applications using it), so it might more naturally fit under /usr/share/fontconfig than /usr/lib/fontconfig. Right?

(In reply to Matthew Miller from comment #11)
> Rather than moving the cache around -- or, I guess, in addition to it, but
> obviating an concern about FHS or dyanamic, unmanaged files in /usr, could
> we just pregenerate the cache files at _build_ time rather than install
> time? They appear to be arch specifc (well, word size and order specific)
> but not really host-specific.

At this moment, unfortunately the updates at the install time are required to update the directory caches. there are two types of the caches in fontconfig. one is to contain a font meta data to reduce the costs to iterate a font, which could be generated at the build time (for Fedora at least. generally speaking, maybe not, because the unit of the cache are per-directories not per-files). one is to contain a directory meta data to reduce the costs to iterate files in a directory and detect the updates, which is likely to be changed at the install time.

(BTW how about using emacs-nox instead or is this an Atomic Workstation?)

Matthew: do you mean Atomic image build-time?

(In reply to Jens Petersen from comment #16)
> Matthew: do you mean Atomic image build-time?

No, I meant at package build time, but that's no help if it's per-directory rather than per font.

Well, Fedora font package are one directory per srpm, it would probably not be too hard to modify the macro to be one package by rpm (the hard part being filesystem cration which is not automated today). And then rebuild all font packages.

Though, of course, this may harm fontconfig performance. Not sure it it like too many directories. And it would transform noarch packages to arch packages which would be expensive for mirrors, given how bulky unicode fonts are.

On the plus side, installing noto would not kill systems performance for minutes anymore.

There were some discussion in upstream about the cache updates at the runtime these days though, disabling the runtime cache updating may be one of solution for this and build the cache at the build time. the caches won't be updated unless the system administrators runs fc-cache with their privileges.

One thing that makes this more urgent is that libvirt -> qemu indirectly pulls in fontconfig (and tons of desktop libraries), because qemu links to gtk for bad reasons.

(Urgency/priority here meaning for Fedora Atomic Host, I'd like to support installing libvirt.  The workstation is another thing)

(In reply to Colin Walters from comment #20)
> One thing that makes this more urgent is that libvirt -> qemu indirectly
> pulls in fontconfig (and tons of desktop libraries), because qemu links to
> gtk for bad reasons.

Bad and hard to fix, or bad and fixable reasons?

(In reply to Matthew Miller from comment #22)
> (In reply to Colin Walters from comment #20)
> > One thing that makes this more urgent is that libvirt -> qemu indirectly
> > pulls in fontconfig (and tons of desktop libraries), because qemu links to
> > gtk for bad reasons.
> 
> Bad and hard to fix, or bad and fixable reasons?

Bad and hard to fix I'm afraid :-(

QEMU has multiple different frontends it builds support for, SDL, GTK, VNC and SPICE. While users who run VMs via libvirt will always use VNC or SPICE, users who run VMs without libvirt will typically use the GTK or SDL frontend. While we encourage people to use libvirt, we can't simply ignore people who don't use libvirt as they have valid reasons for their choices.

So we have to enable GTK or SDL or both in Fedora. We could probably make a case for dropping SDL support in QEMU in Fedora, as GTK frontend is better these days, but that's going to have negligible impact on the deps pulled in.

There is a desire in QEMU upstream to modularize the codebase so that things can be split off into separately dlopen()able modules, with the intention that it will allow distros to ship all features without having to pull in the whole world at once. This is non-trivial work, especially for UI frontends to QEMU, so I'm not expecting it to be done any time soon.

fixed in fontconfig-2.12.1-4

*** Bug 1456278 has been marked as a duplicate of this bug. ***