On Sat, Jul 27, 2002 at 10:55:14PM -0600, Julian Gilbey wrote: > On Sun, Jul 28, 2002 at 01:31:26AM +1000, Anthony Towns wrote: > > On Thu, Jul 25, 2002 at 08:40:13AM -0600, Julian Gilbey wrote: > > > I'd like to rewrite policy soonish. > > Into what, exactly? > > [...] split policy into three separate docs: > > -- Release Critical Issues > > -- Debian Best Packaging Practices > > -- The Debian Specifications Document
Other possible names for the latter document are "The Debian Standards",
or "Debian Standard Interfaces" or something similar.
> I think this makes a lot of conceptual sense. However, I don't think
> that having three separate documents necessarily makes sense from a
> reader's or editor's point of view.
I'm inclined to disagree: I don't see there being any signficant overlap
in the latter two documents at all, and I also suspect that stuff that
goes in either one will be fundamentally different. To take "version
numbers" as an example, I'd think the DSD would cover the format allowed
by the tools (epochs, upstream, debian, valid characters, how they're
compared, probably future directions ("~")), whereas the BPP would tell
you how to use that: try to avoid epochs, for alpha/pre versioning
use something like "0.99-1.0pre1", how to base versions on dates, if
you have to change the upstream tarball but upstream haven't released
a new version tack something like "+0" onto the end of the version,
how to version an unofficial release (from CVS eg), and so on.
> Secondly, I absolutely see the value in clearly distinguishing between
> best packaging practices and the Debian policy/specs.
I'm not remotely using the word "specs" as a synonym for policy. They're
not the same, and IMO, not even remotely similar.
There are at least three different axes for "policy" issues:
* violations result in unacceptable packages or violations are bad,
but won't get you hung, drawn and quartered
* automatically determinable or not automatically-determinable
(alternatively "rule can always be applied or rule needs to be
applied with some judgement")
* an interface used by many packages with Debian, or just a way of
doing things that ends up with a good result
IMO, "policy" encompasses *all* of those things. Trying to limit it to
just the interfaces, or just the things that're always true or can be
automatically tested, or just the things that're unacceptably horrible
is unreasonably limiting, IMO.
I'd consider it quite reasonable to have the BPP and DSD docs in
debian-policy.deb, or to have two different .debs both maintained by
this list, or similar.
> However, to
> have to read two documents to find out how to package a library, which
> are likely to end up overlapping and probably contradicting each
> other, seems unhelpful, to say the least.
debian-policy as it's stands overlaps with itself and contradicts
itself. Avoiding that isn't achieved by having one document instead
of two, it's by maintaining it well. Worse, there are in general many
documents you need to read since a number of subsystem policies have been
(unnecessarily, IMO) split from -policy: menu, debconf, perl, mime (within
the same .deb at least), and python, library packaging, and so forth.
In any event, the BPP and DSD documents are fundamentally different. The
former can have an attitude of "these things work well in a number of
cases, and might work well in yours too", and be a lot more dynamic
and "HOWTO" oriented -- and IMO should have a section dedicated
to the mini-policies of any groups that need them -- perl, python,
games, libs, languages, whatever -- and it could easily refer you to
the DSD for the details if necessary; while the DSD has to be fairly
conservative (you shouldn't include new features, like say ~ in versions
or DEB_BUILD_OPTIONS until everyone supports them -- dpkg, apt, the
archive, and the buildds resepectively).
As another example, the ".deb" section of the DSD document would probably
describe "Essential: yes" as indication to package tools not to allow the
user to remove the package easily, while the BPP document would cover
the fact that essential and required packages are expected to continue
working when unpacked-but-not-configured, and thus should generally use
pre-depends: instead of depends: and should not rely on their postinst
being run in order to work correctly.
It's not clear to me where you'd want to draw the line between putting
some specs in, say, dpkg's documentation versus putting it in a broader
document like the DSD. Things like the arguments to dpkg-buildpackage
should probably stay in dpkg's manpages, even though other tools use them,
but it's probably useful to keep things like the version number format,
and maybe the source package format, or the .deb package format in a
DSD like document.
> To have clearly demarcated
> sections within the document ("Specs/Policy" and "Best practice
> guidelines" in the section on shared libs, for example) would seem to
> get the best of both worlds.
I really don't think so. I've tried rewriting a bit of policy into
BPP style, and it started becoming quite uncomfortable when I got to
the version-number section. The issues just aren't suited to the same
document.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``If you don't do it now, you'll be one year older when you do.''
pgpTpWbRMUHrB.pgp
Description: PGP signature
