Re: Bug#21969: debian-policy: needs clarification about Standards-Version
> From: Remco Blaakmeer <remco@Cal011205.student.utwente.nl> writes:
. . .
> The "no package should be broken" rule isn't wrong, but any other rule may
> be wrong. The problem is, you don't know a rule is wrong until you
> encounter a package that breaks itself or other packages if you follow
> that rule for that particular package. The "binaries should be stripped"
> rule is a good example here.
> My view is this: if you think one or more packages break if a particular
> part of policy is followed, then that part of policy is broken. And if
> something (a package, policy or whatever) in Debian is broken, a bug
> should be filed against it.
> Does anybody disagree with the above paragraph? If not, can this
> discussion please stop? I am getting the impression that everybody already
> agrees with everybody else without knowing so.
A major deficiency of the present Policy Manual is that it does
not define the words "Shall", "Should", "May", etc. Shortly before
this controversy started, Christian posted a proposal to insert such
terms in the document, but this proposal seems to have been lost in
the intervening sound and fury.
I believe the (unwritten) rule "no package should be broken" _is_
wrong. (Should is suggestive.) It should read "no package shall be broken".
(Shall is mandatory.)
Section 3.3.1. of the Policy Manual says:
: Generally the following compilation parameters should be used:
: CC = gcc
: CFLAGS = -O2 -g -Wall # sane warning options vary between programs
: LDFLAGS = # none
: install -s # (or use strip on the files in debian/tmp)
: Note that all installed binaries should be stripped,
This rule is not broken. The use of "Generally" and "should"
make this strongly suggestive, not mandatory. Stripping of binaries
is generally a desirable thing, but may be deviated from when
IMHO, the instances where stripping the binaries breaks a package
are so rare, and the advantages of doing so are so great, that the
developer who finds it necessary to deviate from this policy should
note it, and give his reasons for doing so, in the changelog, in a
README, or elsewhere.
Throughout the policy documents, Christian has chosen his words
with care, but many of the objectors have not read the documents as
carefully as they were written.
|_) _ |_ Robert D. Hilliard <email@example.com>
|_) (_) |_) Palm City, FL USA PGP Key ID: A8E40EB9
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com