Dne 21.12.2016 v 18:08 Matthew Miller napsal(a): > On Wed, Dec 21, 2016 at 11:18:54AM -0500, Randy Barlow wrote: >>>> to move it to /usr/lib/fontconfig/cache. >>> This proposal likely is incompatible to the FHS. >>> >>> Files in directories below /usr/lib are supposed to static and not >>> to be dynamically created. >> I agree - let's not violate FHS. > Keeping to standards where they make sense is valuable. In this case, I > want it to be clear that this isn't just a "doesn't meet red tape! > denied!" stamp — the desire is to avoid runtime-generated files under > /usr, right? While you are afraid, I see in the bugzilla a lot of "it was done previously, we can do it again". And next time this case will be used as a justification for moving more and more stuff into /var. > > When I look at the details, this seems like an edge case. See the > linked bug (https://bugzilla.redhat.com/show_bug.cgi?id=1377367). This > isn't really _runtime_ variable content. It's generated at > package install time. The FHS says: > > /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. > > ... and the thing is, this particular cache is generated during > "installation and software maintenance". > > I see that the fc-cache data is arch-specific, but is it really > host-specific? What if we just pre-generated it at *build* time and put > it into /usr/share or /usr/lib? I guess that'd end up making font files > archful, but that's not the worst thing. I live under impression (may be wrong) that it should be safe to delete content of /var/cache on disk restricted devices ... Vít > > Hmmm, I see that the arch-specific part is encoded in the filename > (like d3379abda271c4acd2ad0c01f565d0b0-le64.cache-7). None of this > stuff is very big; only a few k per font. What if we just included all > of the arch-specific files in every font package? > > Bonus: less stuff run in %post scripts! > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
