On Tue, May 22, 2001 at 01:28:08AM -0400, Raul Miller wrote:
> > Personally, I'd've thought policy was the exact list to discuss this
> > on and get consensus: it's implementation of a technical change that
> > effects a number of packages and has a real need to be documented (since
> > not having it documented has caused all sorts of tasks to be created which
> > shouldn't be tasks).
> Er.. except for one message from Joey (on May 7) I don't see any
> interaction with the author of tasksel. Personally, I'd consider that
> sort of interaction extremely valuable for this sort of thing.
Randolph's busy doing other things unfortunately (otherwise we'd probably
have had a changed implementation ages ago), Joey H and I've been in contact
with him privately.
> I don't think that you should ever consider policy to completely cover
> all release issues. Use it as a checklist, certainly, but its value
> comes from its stability -- making last minute changes to policy makes
> about as much sense for the release as making last minute changes to
> the kernel interface.
Uh, riiight. That analogy is *completely* nonsensical.
> > I'm amazed that -policy is (has become?) so arduous for such things.
> Honestly, do you think that your proposal should not be changed
> during implementation?
Honestly, I don't think it'll change at all during implementation. The
proposal you've got describes the design and barely goes into any detail
at all.
And if it does change, then we just adjust policy to match. Policy's
meant to be a lightweight process, remember.
> You're our release manager -- you're the
> last person I'd expect to want to be changing the ground rules
> for debian at the last minute.
Changing the way tasks are handled has nothing to do with "changing
the ground rules for debian". It effects, quite literally, 56 packages
(55 task packages and tasksel), or about 0.8% of the distro.
> Think about it: if you force this through policy AND require that all
> prior policy be canceled, so that all effected packages must follow this
> new policy, you'll be forcing a policy review of every package in
> debian -- with attendant changes.
And again, this policy has *no* effect on packages that aren't named
"task-something". It doesn't stop people from reuploading their packages
with a different name. For most of the tasks, it doesn't stop them from
being tasks, at all.
> > Should I (do I have to?) fork policy and have a
> > "ajs-official-release-policy-and-errata.deb" or something? I would
> > like to have a fairly precise (and accurate) list of which bugs
> > deserve RC bug reports for woody, by the end of next month and random
> > other policy for the release (eg optional packages not conflicting,
> > and packages not depending on lower priority packages, and packages
> > being consistent across architectures and such). Is debian-policy
> > really unsuitable for that?
> Basically: debian-policy isn't release oriented.
Nor need it be.
All it has to do is describe what packages in unstable should look like.
Seriously, that's all it has to do. It doesn't have to specify what
they should look like in five months when some transition or other is
completed; it doesn't have to say what they looked like five months ago;
just how they should look right now. It doesn't have to be particularly
precise about it: we've got the maintainer's judgement, the ftpmasters'
judgement, the RM's judgement and the tech ctte's judgement to fall back
on if something's not specified quite right.
Generally, we don't want to declare what's in unstable as completely
wrong right now. So, in general, it's best to be conservative about
adding "musts". In this case though, we do. Sometimes you need to make
exceptions to general rules. That's life.
> > If so, what is it suitable for, exactly?
> It represents those parts of debian which are fairly stable in character,
> which a package maintainer can rely on in designing a package. It also,
> to some degree, represents an interpretation of debian's goals.
So it's more of an historical document than guidelines for how packages
should be built now?
(This certainly seems an accurate statement of what policy *is* right now,
as opposed to what it should be.
Going through the functional changes (ie, ones that influence how packages
should be built) from recent policy uploads, we see:
* /var/mail / /var/spool/mail: proposed and essentially agreed
upon in October 1999, implemented in base-files, finally
included in policy in April 2001 (42052)
* Perl policy: developed completely separately from policy,
implemented by the perl maintainer, and included as a separate
document
* Debconf: allow the use of debconf, in Jan 2001; well after a
release that included debconf in base, a year after that release
entered its freeze, and well over that since packages actually
used debconf.
* Multiple maintainers: allow many people to maintain a package in
Jan 2001, two and a half years after the original (?) flamewar
about it.
* /usr/doc exludability: don't allow files in /usr/doc to be
referenced by other programs (so you can exclude it and not
have things break)
(and that seems about exhaustive for all the changes to policy this year
that should really effect anyone). That's not to say policy hasn't had
lots of changes: there's been lots of little cleanups and rewordings
and other such stuff, the packaging manual's been merged which has been
a long standing bug, really; but policy really doesn't seem to be doing
the job of documenting how Debian packages should behave and what they
should look like.
From the policy abstract:
This manual describes the policy requirements for the Debian GNU/Linux
distribution. This includes the structure and contents of the Debian
archive and several design issues of the operating system, as well as
technical requirements that each package must satisfy to be included
in the distribution.
Am I wrong in thinking it's policy's job to document the technical
requirements for Debian packages? Am I wrong in thinking the policy
editors ought to be doing whatever they can to get a consensus formed
about proposals like 51411, 53582, 53849, 54524, 62996, 69311, 80343,
and 89473, and making sure essentially accepted proposals like 76868 and
54002 get implemented, or get brought up again for propoer approval if
discussion can't even take place without an implementation?
If so, am I also wrong in thinking that someone ought to be doing all
those things and that, if policy indeed isn't going to do it, we'd better
write another document and find some people that *will* do it?
Am I wrong in thinking that having a single, well known document that
describes what packages should look like right now is one of the key
Cool Things about Debian?
Am I wrong?
If I'm not, then wouldn't it be nicer if instead of spending what energy
we have worrying about whether policy should be a stick to beat people
with or whether the RM and DPL should be doing the beating, and wondering
if we should define /bin/sh differently [0], if we instead focussed our
energies on changing policy so it actually help people make packages
that are more useful to our users?
). [1]
Cheers,
aj
[0] Or if we've worded our statement about the FHS quite right... But I know
that's a pet peeve of Chris', and I have enough pet peeves of my own to
know what that's like. :) Speaking of which, end of footnote. ;)
[1] You thought I'd forgotten, didn't you? Go on. Admit it.
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpCEhKMsNlb8.pgp
Description: PGP signature