On Thu, Aug 17, 2000 at 01:08:02PM +1000, Anthony Towns wrote:
> On Wed, Aug 16, 2000 at 12:30:00PM -0700, Chris Waters wrote:
> > Very true. On the other hand, the mere *presence* of /usr/doc is an
> > FHS violation. Therefore, if policy requires compliance *at this
> > point*, it would be self-contradictory. We cannot have symlinks in
> > /usr/doc *and* claim compliance.
> This could be fixed by simply saying "Debian packages should by fully
> compliant with the FHS, except where otherwise indicated in this
> document", or similar.
That would probably be an acceptable solution. It seems to address
Wichert's concern that we should leave ourselves some wriggle-room in
case we need it (like we did with /usr/doc). My main concern is that
it may require highlighting the areas where policy *does* contradict
the FHS (for all our sakes).
And note that "compliant except for X" really translates to
"compatible". Compliance is a boolean condition: you are or you
aren't. I think your proposed solution is a little bit disingenuous,
and perhaps even slightly dishonest. But only slightly; not enough
that I'd actually object.
> We aren't even compatible at the moment: there are many packages for
> which /usr/doc/<package> exists, but /usr/share/doc/<package> doesn't.
Those packages already violate the latest policy documents. And
anyway, that should be my point. How can we mandate compliance when
we haven't even achieved compatibility? We should take this a step at
a time. First, make sure we're fully compatible, then go for full
compliance.
But if you really want to go for "FHS-compliant except where stated"
instead, I could live with that. Just clear it with Wichert, who's
already on record as opposing FHS-compliance at this point. (See bug
60461.)
> Note that the requirement of compatability would leave open the
> possibility of packages installing all their files in /opt/foo-1.2.3/,
> and maintaining symlinks from the rest of the system.
Actually, that's fully FHS-compliant behavior, as far as I can tell
(/opt is certainly FHS compliant -- see 3.8 -- and the symlinks should
be as long as they're all in FHS compliant locations). The only way
we can rule that out is to forbid it in our *own* policy. Which we
*already do*. Being FHS compatible (or compliant) does not give you
license to violate Debian policy!
> I don't think this should be considered policy compliant.
Quite true, but irrelevent to the current discussion of *FHS*
compatibility/compliance.
In any case, there is already a proposal on record (#60461). If you
feel *so* strongly about this, you should probably quick-like-a-bunny
file your objections to that. Assuming you can find some more
relevent objections. :-)
Maybe we should say, "packages must be compatible with FHS, and should
strive for compliance, except where explicitly forbidden by this
document." Or words to that effect.
*shrug*
cheers
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or [EMAIL PROTECTED] | above, but it is too long to fit into
| this .signature file.
