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

Re: Debian and FHS

On 3 Mar 2000, Manoj Srivastava wrote:

>  Steve> Poking around in /usr/share/doc/debian-policy, for example, I
>  Steve> see a "proposal" document.  This document is written as a
>  Steve> *proposal* to propose policy changes, so I was unsure of its
>  Steve> status.  It is over a year old, so I had assumed that the
>  Steve> proposal has been adopted without the language being updated
>  Steve> to read as a *policy* on proposing policy changes :).
>         Umm, we like to keep things informal around here. So that
>  document kinda reflects the way things are done, without having the
>  weight of policy. 

If so, I do humbly suggest it be written as a "best practices" document,
and not a "proposal" document.

>  >> My first comment, though: I doubt that we want to specify the version
>  >> of the FHS.  I realize that there's a little ambiguity if we don't,
>  >> but A) I don't think we want to revise policy every time the FHS is
>  >> updated, 
>  Steve> I think one *does* want to update the policy document each
>  Steve> time the FHS is updated.  Otherwise, the policy can be
>  Steve> invalidated by external forces. For example, when FHS 2.0
>  Steve> specified that /var/state be used in place of /var/lib,
>  Steve> suddenly no packages would comply with policy!  At the very
>  Steve> least, someone ought to audit the changes between FHS versions
>  Steve> to ensure that Debian really can live with the new FHS.
>         I would rather change the policy to specify we try to be
>  compatible to the version of the FHS included in the policy package.

For almost all practical purposes, that amounts to the same thing.

Scenario A: the policy says debian complies with "FHS shipped in the
policy package".  Now a new FHS revision comes out.  Before someone ships
it with the policy package, that person must go through the changes from
the last FHS revision to make sure that Debian can live with them.

Scenario B: the policy says that debian complies with "FHS version x.y".
Now a new FHS revision comes out.  Before the policy document gets
updated, someone must go through the changes in the FHS to make sure
Debian can live with them.

There is essentially no difference in the amount of work required.  

I know the wording of scenario A appeals to computer folks' appreciation
of indirection.  But here there is no gain in being indirect.  To the
contrary, there is a danger of ambiguity if one has the policy document
alone to work with.  Ah, but that would never happen.  Sure.  But if it
costs you nothing to put in a few `sanity checks', the document --- like
source code --- will be improved.


>         I do not think Debian policy should be automatically updated
>  to a new version of the FHS. The newer versions may have things we
>  can't live with. 

I agree.  That's one of the reasons I've been arguing against the current
wording in the policy document.

Reply to: