Hello Russ, Sam,
On Thu 20 Jun 2019 at 09:01AM -07, Russ Allbery wrote:
> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> 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.
Aha, I see.
>> 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.
> [...]
Thank you both for the correction. In hindsight, it would have been
wise of me to review our definitions of the magic words before making an
argument based on how they are defined.
>> 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.
Good point.
> 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.)
My concern is not about making the language too normatively *weak*. I
agree with everything just quoted. Rather, my concern is about the
language being normatively *imprecise*. I wrote:
| I would like to try to make the first sentence normatively clearer. I
| think that it would be difficult to understand exactly what the project
| consensus is from that sentence, had you not read Sam's d-d-a post.
and I still think that. Let me say a bit more. We want to push people
without strong opinions on the matter towards using dh. We could do
that by writing something in Policy which does not use any of the magic
words (like some other tool recommendations in Policy), and in such a
case I would not be raising this concern. However, we have decided that
we want to use the should/recommended words. And I think that when we
use the magic words we should take special care to make it clear to the
reader what the normative content of the sentence is.
Looking at your patch again, I think that my concern could be allayed by
explicitly tying the "There are various situations ..." paragraph to the
"reason to use a different approach" clause. This is the sort of thing
that I mean (I've also wordsmithed):
The recommended way to implement the build process of a Debian
package, in the absence of a good reason to use a different
approach, is the ``dh`` tool. This includes the contents of the
``debian/rules`` building script. ``dh`` is the most common
packaging helper tool in Debian. Using it will usually save effort
in complying with the rules in this document, because ``dh`` will
automatically implement many of them without requiring explicit
instructions.
There are sometimes good reasons to use a different approach. For
example, the standard tools for packaging software written in some
languages may use another tool; some rarer packaging patterns, such
as multiple builds of the same software with different options, are
easier to express with other tools; and a packager working on a new
packaging helper might want to use their new tool. The
recommendation to use ``dh`` does not always apply, and use of
``dh`` is therefore not required.
Other notes on this:
- I changed "a reason"->"a good reason" because this is in fact what we
mean
- saying that use of ``dh`` is "not required" is strictly redundant
because 'required' is equivalent to 'must', and nothing in the
previous paragraph says that you must use dh
- I think I avoid any chance of misreading by reiterating that the
recommendation has exceptions
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature