Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
On Tue, May 22, 2001 at 01:28:08AM -0400, Raul Miller wrote:
> > 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.
On Tue, May 22, 2001 at 09:15:10PM +1000, Anthony Towns wrote:
> Uh, riiight. That analogy is *completely* nonsensical.
I'll grant you that it's not a direct analogy -- changing the kernel
interface would immediately break software, while changing policy only
makes software "non-compliant".
However, changing packages to comply with new policy can break the
software, might require new policy revisions, etc.
> > > 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.
Actually, I don't remember. Pointer?
There's a lot of packages, and many of them have to change to comply
with new policy. Which is one of the reasons we don't ask that all
developers instantly comply with each policy change.
> > 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.
But policy represents "the ground rules for debian". And, if you're
going to use policy to express that the tasksel change is important
for this release, you're going to be revoking all policy which doesn't
have the tasksel change. And that is going to impact a lot more than
56 packages.
> > 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.
All this is relevant if you're speaking from a point of view which doesn't
*require* that this policy be actually used before woody is released.
Which leads to the question: what is the actual requirement here?
> > > 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.
And it isn't even a complete reflection of that, nor was it ever intended
to be.
> 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.
Uh.. but disagreements on these things can be unpleasant to resolve.
Anyways, I don't think it's worthwhile arguing from the point of view
that expects all maintainers to disagree with policy where needed.
> 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.
That's great, but it's still not at all clear what the requirement
is, here. [See above. If you've refuted my points about policy
release management and how policy is used, that would refute this
point as well.]
> > > 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?
There's a whole spectrum of tools that are needed to build pakages.
At one end of the spectrum is the social contract, which is very abstract
and unchanging. Policy is near that end of the spectrum.
At the other end of the spectrum are individual instances of working
packages.
Release management is more abstract than individual packages, and less
abstract than policy.
I'd say that "guidelines" covers maybe half that spectrum (the abstract
half).
Policy does have a historical element, as well as a future element, and
a present element, and none of that conflicts with it being guidelines.
> (This certainly seems an accurate statement of what policy *is* right now,
> as opposed to what it should be.
I'm tempted to insert `dict policy` here.
> 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?
Yes.
It describes some technical requirements -- but only those that fall
under the umbrella of what is commonly meant by the term "policy".
> 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?
Whatever they can?
You mean, like if they could hold people at gunpoint to form a consensus,
they should do so?
Obviously, making sure that the consensus is right is also important.
> 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?
Developers already have complete authority to do whatever they need.
You, as release manager, already have complete authority in deiding what's
critical to the release.
Blaming shortcomings in such area on policy is silly. Policy shouldn't
be the only point of agreement among developers.
> 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?
I think so, if you're implying that we shouldn't have any other
documentation from any other points of view.
> 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?
There's a lot more to debian than policy.
> ). [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.
Cute :).
--
Raul
Reply to: