On Sun, Aug 29, 1999 at 04:52:59PM +0200, Marcus Brinkmann wrote:
> On Sun, Aug 29, 1999 at 06:08:54PM +1000, Anthony Towns wrote:
> > Let me put it yet another way. We should be willing to add a lintian
> > check for any additions to policy, and file severity: normal bug reports
> > for every package in violation. (Which isn't to say we actually *should*,
> > but we shouldn't make policy where that would be unreasonable)
>
> I think that does not make sense at all.
>
> Let's consider changing the source format. We could either change the policy
> manual first, and then let packages folow it, or wait until many packages
> are converted and then adopt policy.
Or we could initially change policy to say `Debian packages should use
either the new source format (preferred), or th old one.', and then,
at some later point change it to say `All Debian packages should use
the new source format'.
> I don't see why the second shall be better than the first.
In this example, specifically saying "Either could be used" warns tool
writers that they shouldn't expect to be able to deal with the whole
Debian archive if they don't cope with both formats. It lets people make
a rational choice between using one or the other if there are actual
reasons to use the old format (eg, dpkg is still buggy and doesn't
cope with some packages when they use the new format) while still being
policy conformant.
> I also can't see why a package warrants a bug when it does not follow the
> latest policy. Every package has a standard-version attached to it, which it
> claims to follow. Only if packages bump the version number before following
> the policy of this version, it shall be a bug.
Eh? From policy itself: ``This value will be used to file bug reports
automatically if your package becomes too much out of date.''
You don't get to choose which version of policy you prefer on a package-by-
package basis. Standards-Version: is just a good way of saying "Yeah, I
know I'm out of date. Sorry.''
Consider something like: ``Your package has /usr/doc/copyright/package
instead of /usr/doc/package/copyright''. That almost certainly doesn't
cause a problem with the package itself. And the copyright is included,
and it doesn't actually get in anyone's way in particular. So, afaict,
the only reason to consider it a "bug" is because it doesn't conform
to current policy. I think it's perfectly reasonable to file bugs about
that, even if the package has a Standards-Version: header that matches
a version of policy that says to do it that way.
I don't think it's reasonable to file bugs about "Your package uses
FSSTND locations instead of FHS locations" right now though --- I don't
think anyone really expects all packages to convert this instant. And
I just think we should be explicit about that: if we don't think it's
a bug to have a package that does one thing, we shouldn't demand that
packages do some other thing in policy.
From the _Scope_ section of policy:
] This manual describes the policy requirements for the Debian GNU/Linux
] distribution. This includes the structure and contents of the Debian
] archive, several design issues of the operating system, as well as
] technical requirements that each package must satisfy to be included
] in the distribution.
In particular the last section: technical requirements that each package
*must* satisfy to be included in the distribution.
Did I make any more sense this time? *vaguely hopeful look*
Can you agree that having policy say "You can do either <foo> or <bar>,
but we'd prefer <bar>" is better than having policy say "You must do
<bar>", but telling everyone that it's not important that you change from
<foo> to <bar> just yet if you don't feel like it; even if you think my
reasons why this is so are naive and nonsensical?
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgpd3AKE0qXsY.pgp
Description: PGP signature