Re: /usr/doc transition and other things
On Mon, Aug 30, 1999 at 01:57:51AM +1000, Anthony Towns wrote:
>
> > 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 don't think this is necessary. Such bugs in dpkg must be fixed, and as
long as it isn't fixed there is no problem with having non-policy compliant
packages in the archive.
If policy always is behind the actual development of the distribution, we
can't be very productive in our work. I am positive that there is no
contradiction, as we don't need to file bug reports, even if a lot of
packages are not policy compliant. Read on.
> > 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.''
Allright. But the critical words are "too much". We accept a time of
non-compliance between releasing a policy with a new standards version and
filing bug reports. How long this time is is not specified in the policy
manual, so we can interpret this depending on the situation.
> 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.
Right.
> 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.
Yes, it is reasonable _today_, but it wasn't reasonable a few years back
when the change was introduced. It seems I suggest the following order:
1. Change policy.
2. Fix bunch of packages.
3. File bug reports for the remaining unfixed packages.
Whereas you and Raul seem to suggest (please correct me if I am wrong):
1. Make informal decision about something OR make decision and change policy
to allow old and new way.
2. Wait until enough packages follow the new way.
3. Change policy again to make recommendation obligate.
4. File bug reports fast.
This seems to have two problems: First, it creates more overhead (you have
to change policy twice). Secondly, it doesn't speed up the transition,
because less people will feel compelled to chnage their packages to comply
with the new policy, so you will have less packages complying to the new way
the time you make it an obligation.
> 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.
I disagree with you for the above reasons. I don't see this conflict. To me,
it seems to be perfectly fine to do exactly that. (indeed, I couldn't have
find better words. I think it is perfectly fine to demand one thing but not
punish(=file bug reports) for some time, until they get "too much out of
date").
> 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*
Yes, I think we are at the heart of our diasgreement. I also see your point,
but still I prefer it the other way *blink* ;)
The Debian policy is an "idol". We should always try to reach compliance,
but we should not "turn it down" because we can't comply.
Of course, modesty is also a nice thing. It just doesn't carry you very far,
IMHO. The danger is that the time you want to make the final change gets
delayed over and over again.
> 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
I agree, but this is not what I say. What I say is:
"You can do either <foo> or <bar>, but we'd prefer <bar>"
is worse than
"You must do <bar>, and if you don't do it within time we will start to file
bug rpeorts"
Especially I would never say that "it's not important that you change
if you don't feel like it"
I hope I explained myself better.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@
Marcus Brinkmann GNU http://www.gnu.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: