On Sun, May 19, 2002 at 05:05:54PM -0500, Adam Heath wrote:
> On Sun, 19 May 2002, Steve Langasek wrote:
> > On Sat, May 18, 2002 at 11:49:45PM -0500, Adam Heath wrote:
> > > On Sat, 18 May 2002, Branden Robinson wrote:
> > > > > Why not just use /libexec, for hurd, and be done with it? Why force the rest
> > > > > of Debian to require use of it?
> > > > As I understand it, that's all they're asking for. But Debian Policy
> > > > says "follow the FHS", and {/usr,}/libexec doesn't. And some non-Hurd
> > > > Debian developers are sufficiently enamored of the concept of Policy as
> > > > universally applicable without exception that it feels like anti-Hurd
> > > > discrimination to some people.
> > > I don't see that adding /libexec on hurd is a violation of policy.
> > It most definitely would be. All files that the Hurd port wants to put
> > in {/usr,}/libexec are required by the FHS to be placed in
> > subdirectories under /usr/lib. Because Debian Policy says we must
> > follow the FHS, it's pretty clear that this is not currently acceptable.
> Hint: policy is wrong, so ignore it here. Then, you'll have no problems.
> Policy is not a stick used to beat people with. It's a guideline. Policy has
> never said it was 100%.
> In this event, policy is behind the times. So, you implement
> something(/hurd|/libexec), and when things are working with your
> implementation, policy is modified to document and describe the
> implementation.
> Policy is never modified first.
On the contrary. In cases where Policy will be changed to place a new
*restriction* on packages, consensus and compliance must be built first
before Policy changes are made. In this regard, Policy should not be
used as a club, because gratuitously causing packages to become
Policy-incompliant breeds ill-will and doesn't get real problems fixed
any faster. However, the Hurd port is asking for Policy to be
*relaxed*, which means there should be consensus first that it should be
relaxed (as well as /how/ it should be relaxed), for the same reason:
gratuitously ignoring (rather than amending) Policy results in packages
that are gratuitously incompliant with Policy. I recognize that in the
specific case of an unreleased port such as hurd-i386, there is a need
to getting the system working, and that at various points during the
evolution (both of the port and of Policy), not everything will be in
complete compliance. Even so, saying "Policy is wrong" is quite
different from saying "This is not a policy violation", and each calls
for very different actions.
Also be careful of the "Policy is not a stick" mantra. It's true that
Policy is not a perfect, static thing; but in cases where a certain
behavior is well-defined in Policy, it is not the prerogative of the
individual maintainer to make changes to his packages which ignore
Policy. This is, after all, why policy violations are considered RC
bugs by default.
Steve Langasek
postmodern programmer
Attachment:
pgpK_B8HTPjJJ.pgp
Description: PGP signature