Hi Colin,

On Mon, Mar 10, 2014 at 10:41:36PM +0000, Colin Walters wrote:
> Redirecting this here, per reply
> http://sourceforge.net/p/freestandards/mailman/message/32084653/

> Martin: While I do personally encourage programs to follow the
> systemd style of having configuration defaults in /usr/share or
> /usr/lib, this proposal is completely orthogonal - it's about
> defaults in /etc, and even systemd has some of those.

> Hi,

> 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".

> (OSTree is not actually a package system, but I use the term to
> avoid confusion)

Existing implementations make /usr a symlink to /, which AFAICS is perfectly
allowed by the current standard.  So this doesn't seem to me like something
that should have an exception made for it.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[email protected]                                     [email protected]

Attachment: signature.asc
Description: Digital signature

_______________________________________________
fhs-discuss mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/fhs-discuss

Reply via email to