On 29 Feb 2000, Manoj Srivastava wrote:
> >>"Steve" == Steve Robbins <[EMAIL PROTECTED]> writes:
>
> Steve> Hmm. This says that the *location* of directories must comply with
> FHS.
> Steve> Why doesn't this read simply "The Debian file system must fully comply
> Steve> with FHS"? Is it intended that Debian follow the FHS only in
> *location*
> Steve> but not in *intent* or *use* of directories? For instance, FHS
> allows the
> Steve> directory location /usr/lib. Can I ignore the *intent* of /usr/lib,
> and
> Steve> put a user-executable binary in it? Or am I reading too much into
> this
> Steve> bit of policy?
>
> Steve> Well, let's assume that I'm reading too much into this, and that the
> Steve> Policy writers really intended that Debian be fully FHS compliant.
>
> Actually, no. We never intended full compliance when that was
> written (people had major misgivings regardin /var/state, var/lib/
> etc (the FHS has changed since)). There was also the issue of
> /var/spool/mail ...
Ah. I confess ignorance of this debate, and I see no way to divine the
policy intention from the policy document.
> So the intent was that we shall try to be as compliant as
> possible, without chaining ourselves the what is an evolving
> standard.
It would be helpful for people in my situation (i.e. coming in late) if
the policy section on the file system be revised to say something like:
Debian strives to follow the FHS. Packages must comply with
FHS (version x.y) with the following exceptions
(a) /var/state
Debian policy on /var/state is ...
(b) /var/lib
Debian policy on /var/lib is ...
...
You see? If the policy is spelled out explicitly, there is less chance
for bozos like me to misunderstand. It would be even nicer if some of the
"rationale" arguments are presented; e.g. exactly why is the FHS
specification of /var/state a problem.
> We may, of course, decide to revisit that stance.
OK. Since the FHS is evolving, it is important that the policy document
spell out exactly WHICH VERSION of FHS one is attempting to comply with.
Currently the policy does not do this.
Cheers,
--Steve
