On Thu, Aug 17, 2000 at 09:59:18AM -0700, Chris Waters wrote:
> > 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.
> 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.
Actually, according to the FHS in literally translates to "partially
compliant". I can't think of a way of phrasing it with those words that
doesn't make it sound like "maintainers can be compliant when they feel
like, whatever dude".
> > 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.
Well, see, that's the thing: we *are* doing it one step at a time. That's
the whole point of the /usr/doc transition.
The way policy reflects this is to say what our end goal is rather than
merely documenting existing practice. This may be a bug in the way we
write policy.
> > 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!
We do? I thought we just referred to the FHS to say where files should go,
generally. Could you point out the place in debian-policy that says this
isn't legitimate? I may be just blind.
And things like having /sbin/ifconfig physically located in /sbin rather
than a symlink somewhere *is* required for FHS compliance, but not for
FHS compatability, umm:
] An implementation is fully compliant with this standard if every
] requirement in this standard is met. Every file or directory which is
] part of the implementation must be physically located as specified in
] this document. [...]
Consider putting all files from a package in /usr/lib/my-special-package
and symlinking to there from /usr/bin or /etc or wherever instead then,
perhaps.
> > I don't think this should be considered policy compliant.
> Quite true, but irrelevent to the current discussion of *FHS*
> compatibility/compliance.
Again, as far as I can tell, the only thing that makes it non-policy
compliant is that it's non-FHS compliant, and policy requires FHS
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.
A proposal that hasn't been seconded at all and hasn't seen any discussion
since March, according to the bug logs. Forgive me if I don't see the
urgency.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgpQVcPqmv0Ai.pgp
Description: PGP signature