bug-standards
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Conflict between GNU CS and FHS


From: Tom 'spot' Callaway
Subject: Re: Conflict between GNU CS and FHS
Date: Sat, 18 Mar 2006 09:59:11 -0600

On Sat, 2006-03-18 at 13:46 +0100, Linus Walleij wrote:
> As has been found in the Fedora Core bugzilla, we discovered a conflict 
> between the GNU Coding Standards and FHS.
> 
> Quoting FHS:
> (http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE18)
> 
>    "/usr is shareable, read-only data. That means that /usr should be
>     shareable between various FHS-compliant hosts and must not be written
>     to."
> 
> Quoting GNU Coding Standards:
> (http://www.gnu.org/prep/standards/html_node/Directory-Variables.html)
> 
>    "'sharedstatedir'
>     The directory for installing architecture-independent data files which
>     the programs modify while they run. This should normally be
>     /usr/local/com, but write it as $(prefix)/com.
> 
> Since the latter will resolve into /usr/com if $prefix is /usr (which is 
> common when building a package for a system), a conflict arise, where FHS 
> says it should not be written to, whereas GNU CS says it is even 
> recommended to do so, provided the data is architecture-independent.

I'm pretty sure the GNU CS is wrong here. There are very good reasons to
let /usr be read-only. IMHO, /var/ would be a much better place for a
sharedstate directory.

Of course, right now, %{_sharedstatedir} resolves to %{_prefix}/con in
the rpm macros. I'd rather see us use %{_localstatedir} (/var).

I think we have two options:

1. Wait for the GNU CS or the FHS to resolve this disconnect.
2. Use %{_localstatedir} in place of %{_sharedstatedir} for apps that
care about sharedstatedir to not violate the FHS.

~spot
-- 
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!





reply via email to

[Prev in Thread] Current Thread [Next in Thread]