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

Re: Conflict between GNU CS and FHS

On Sat, 2006-03-18 at 20:37 -0600, Tom 'spot' Callaway wrote:
> On Sat, 2006-03-18 at 22:58 +0100, Alfred M. Szmidt wrote:
> > That corner case operating system is used world wide, and you (I
> > assume so by your email address) work for a company that produces a
> > variant of the GNU system.  So it isn't presumptious at all, on the
> > contrary...
> Based on this information, since Linux uses /usr, and it is not
> presumptious to assume that we should not be using /usr, all packages
> storing files in /usr are hereby in violation of all of the Fedora
> Extras Packaging guidelines.
> That's assuming that the Fedora Extras Packaging guidelines stated that
> the GNU CS was to be followed. Which it most certainly does not.
> I believe that the FHS trumps the GNU CS.
Neither trumps anything.

The points you seem to be ignoring: 
* The GCS is a CODING standard.
* The FHS is a FILE HIERARCHY standand.

These are completely different tasks.

All the GCS does, is to specify that packages (i.e. developers) should
consider/honor a "sharedstatedir" for which the GCS authors make certain

The GCS's proposals do not fit well into the FHS, a fact, which I
consider to be a gap of the FHS. I presume this gap exists deliberately,
because standardizing sharing data between systems is hardly possible in
real world.

I.e. I don't see any "x trumps y" relation, but consider the whole issue
to be a question of implementation. I.e. system integrator's/vendor's
task to choose/implement a specific convention that complies to both for
a product (such as Fedora).

>  Thus, thou shalt not store
> stateful data in /usr/con. Feel free to put it in /con, or /var, or
> anywhere else that doesn't violate the FHS.
Technically /com would be nice solution (and I've seen this being used
in real world), but as others already pointed out, this violates the
current FHS.

> Is that good enough? I'm willing to hear reasonable arguments that don't
> involve tunnel vision, otherwise, this is the policy I'm taking to
IMO, from FE's POV, this whole issue boils down to a bug in
RPM. /usr/com is definitely wrong.

Now, it's up to the RH and FESCO to find an reasonable, FHS compliant
convention of how to implement a "sharedstatedir" in Fedora and up to
RH's rpm integrators to decide on how to implement it in rpm.

IMO, using /var as "sharedstatedir" would probably work in 99% of all
cases, but I thinks will only a matter of time until you'd find a clash
between "localstatedir" and "sharedstatedir", so I'd be leaning
for /var/com or similar.


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