Re: Rewriting policy soonish if poss.
On Sun, Jul 28, 2002 at 05:34:52PM +1000, Anthony Towns wrote:
> > 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.
Absolutely agreed that these are different. However, how does it
serve our developers to have to look at two different documents when
trying to find out how to come up with a version number? This issue
has, as you point out, two clearly different aspects, which would be
separated in any intelligent document, but there are other issues
where the distinction is far less clear. (See, for example, all of
the examples in the current policy.) I am *not* advocating munging
everything into one confused paragraph, but clearly distinguishing
examples and guidelines from standards/specs within one, easy-to-read,
document.
> > 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
RCness; I think we're agreed that this is ultimately the RM's decision
(with the possibility of appropriate discussion on particular cases).
> * automatically determinable or not automatically-determinable
> (alternatively "rule can always be applied or rule needs to be
> applied with some judgement")
MUST/SHOULD (in the RFC sense).
> * an interface used by many packages with Debian, or just a way of
> doing things that ends up with a good result
Now here's the crunch: this is a description of best practice
guildlines. But as you say, "policy" encompasses this. And I agree
with you.
> 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.
Our only disagreement seems to be over how the document/s is/are
structured, not over the responsibility and content.
> > 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.
Agreed.
> Avoiding that isn't achieved by having one document instead
> of two, it's by maintaining it well.
"Avoiding that isn't NECESSARILY achieved ...."
> 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.
Agreed.
> 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).
To split the (often borderline) cases of specs versus guidelines seems
to me to be somewhat misguided.
Anyway, once I have something workable for a part of the new document,
we can take a look at it and comment further.
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
website: http://www.maths.qmul.ac.uk/~jdg/
Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
Visit http://www.thehungersite.com/ to help feed the hungry
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: