Bug#930666: Please document consensus on use of dh sequencer
Sean Whitton <spwhitton@spwhitton.name> writes:
>> --- a/policy/ch-source.rst
>> +++ b/policy/ch-source.rst
>> @@ -259,18 +259,49 @@ files, sockets or setuid or setgid files.. [#]_
>> Main building script: ``debian/rules``
>> --------------------------------------
>>
>> -This file must be an executable makefile, and contains the
>> -package-specific recipes for compiling the package and building binary
>> -package(s) from the source.
>> -
>> -It must start with the line ``#!/usr/bin/make -f``, so that it can be
>> -invoked by saying its name rather than invoking ``make`` explicitly.
>> -That is, invoking either of ``make -f debian/rules args...`` or ``./debian/rules args...`` must result in identical behavior.
>> +This file must be an executable makefile. It contains the
>> +package-specific recipes for compiling the source (if required) and
>> +constructing one or more binary packages.
>> +
>> +``debian/rules`` must start with the line ``#!/usr/bin/make -f`` so that
>> +it can be executed by running ``./debian/rules`` from the top of the
>> +source package. Invoking either of ``make -f debian/rules <arg> ...`` or
>> +``./debian/rules <arg> ...`` must result in identical behavior.
> I must admit to being sad to see the demise of "invoked by saying its
> name", but this is probably a sensible change.
I probably shouldn't have muddled this patch with the wording
clarification, but I found the previous text a bit confusing. It's a nice
turn of phrase, but I've never seen anyone elsewhere refer to running a
script via a relative path as "saying its name."
> A tiny thing is that you seem to have switched "<args>" for "<arg>",
> which seems wrong.
I'll put this back to args... since it just muddles the discussion, and we
can talk about that separately some other time. But, for the record,
"<args>" would imply that all the arguments have to be given as a single
argument and would be later split, as opposed to "<arg> ...", which allows
for one or more arguments.
> However, any SHOULD requirement in Policy implicitly has that structure:
> "you should X unless there is reason not to X". Perhaps MUST
> requirements don't have that implicit structure, because perhaps the
> idea in such cases is that there is never reason not to X.
I agree with Sam that this is not the way Policy is currently written.
This *is* what RFC 2119 SHOULD means, but this is one of the places where
Policy diverges from RFC 2119. We say:
| Non-conformance with guidelines denoted by *should* (or *recommended*)
| will generally be considered a bug, but will not necessarily render a
| package unsuitable for distribution.
which isn't as clear as it could be, but doesn't leave clear room for
maintainer discretion or other reasons, just a lot of room for severity.
Compare to RFC 2119:
| This word, or the adjective "RECOMMENDED", mean that there may exist
| valid reasons in particular circumstances to ignore a particular item,
| but the full implications must be understood and carefully weighed
| before choosing a different course.
which is much weaker than Policy should.
> Would it be right to say that what we are trying to express is the idea
> that dh should be used when there aren't *package-specific* reasons not
> to use dh, and for new packages, we're recommending a workflow of
> starting with the assumption that no such package-specific reasons
> exist?
I don't think so, since this doesn't account for a maintainer who is
writing a new packaging helper, which is not a package-specific reason
(it's a maintainer-specific reason). I also don't think the project
consensus was to tell Jonas (the cdbs maintainer) to use dh for all new
packages.
I understand the concern about making the language too weak, but I also
don't think there's a need to be too firm here. The goal, at least as I
see it, is to push people who don't have strong opinions towards dh, not
to try to convince the people who do have strong opinions. (I think that
convincing is worthwhile but I think it will happen organically and Policy
isn't really the place.)
> I find the expression "default content" odd in this context, I think
> because defaults are things that executable programs have, not source
> code.
> Can I suggest we talk instead about the "starting point for the content
> of d/rules" and say something like "this starting point is often
> sufficient to build a package satisfying most of the requirements below
> (and many others), and where it is not, package-specific instructions
> are usually expressed using override targets" ?
That sounds great to me. I'll make that change in my draft.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: