Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Sean Whitton wrote:
> On Thu 02 Aug 2018 at 07:29PM -0700, Jonathan Nieder wrote:

>> Thanks.  Unfortunately, that wouldn't address Clément's concern about
>> maximal verbosity (1) not being consistent with reasonableness and (2)
>> not being concrete enough to easily act on as a packager.
[...]
> Hmm.  The original goal of the requirement might well have been not
> abbreviating build command lines, and I agree that package maintainers
> should avoid abbreviating those.  However, ISTM that a more general
> recommendation in favour of verbosity is also useful, and should not be
> removed.  An example that comes to mind is test suite output: you really
> do want that to be quite verbose in order to see what went wrong.
>
> We have to rely on maintainer judgement about what to include.

Thanks for explaining your point of view.  I agree with relying on
maintainer judgement, and the best way to do that is to avoid having a
requirement in policy at all in some areas.

I think it really does help to look at the motivating use cases.  If
we focus on what it would be a good idea for a packager to do, then
policy would become very long, and it would become much less useful as
a precise source of information about Debian's packaging policies.
Instead, I find it more useful to focus on the non-obvious bits where
having a documented policy can help.

If I understand correctly, you're saying that the following fall into
that category:

- don't abbreviate build commands unless DEB_BUILD_OPTIONS=terse
- don't abbreviate test commands and output unless
  DEB_BUILD_OPTIONS=terse

Do I understand correctly?  Are there more examples in that category,
or could we just document those two?

[...]
> 1) Add something like "In particular, build command lines should not be
>    abbreviated."  Then we are not leaving that particular case up to
>    maintainer judgement, without removing the general recommendation.

This wouldn't help Clément's motivating example, since it would not
clarify whether there is additional verbose output he needs to
provide.

> 2) Add some examples of what should usually not be included, or perhaps
>    just say that if some output makes a build log tens of megabytes in
>    size, it should not be included.

I feel that this is trying to solve a problem that doesn't need
solving: packagers generally have good taste, and for most purposes it
is obvious to packagers what outputs they need to include (after all,
the packager is the primary audience of these logs!)  Build command
lines really are a special case since they are important to the
toolchain maintainers.

The size threshold you mentioned would suggest that the Linux kernel
should not support unabbreviated build logs.

> 3) Deal with the 'maximally' problem with one of the rewordings I
>    suggested in a previous message -- we want to include mention that
>    it's debian/rules that does the work of enabling the reasonable
>    verbosity.

Removing 'maximally' might help, but it doesn't significantly change
the basic problem of the current text not being tightly scoped or
providing clear guidance.

Thanks and hope that helps,
Jonathan