Colin Walters <[email protected]> writes: > I have a project called "OSTree": https://live.gnome.org/Projects/OSTree
> It's a new upgrade system for general purpose Linux-based operating > systems, designed to complement packages - you feed it packages on a > build server, and replicate the content to clients. > Now, in order to make upgrades *atomic*, I need a place to store > configuration defaults, so that on updates, I can do a 3-way merge into > a new configuration area, rather than live-mutating your running /etc. > In order to have a place to store the defaults, I just picked /usr/etc. > It was pointed out to me that FHS 2.3 says: > "Note that /usr/etc is still not allowed: programs in /usr should place > configuration files in /etc." > OSTree is actually following this in that no program *other* than OSTree > is reading /usr/etc, and nothing is writing to it (since /usr is > read-only). > Can we add exception text to the effect of "Some package systems may > store defaults in /usr/etc - programs other than these package systems > should not read them". Could you say more about why you believe the right fix here is to add an exception to the FHS, as opposed to moving your files from /usr/etc to /usr/share/ostree/etc, which would be FHS-compliant? Given that nothing other than OSTree looks at those files, it seems like that should be an easy change and no other part of the system would care where those files are. That sort of application-specific data storage is the whole point of application-specific directories under /usr/share or /usr/lib, so that seems like a good fit for your user case. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ fhs-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/fhs-discuss
