[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Hello Jonathan and Clément,

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

>> We could restore your text in a footnote or a "For example ..."
>> paragraph?
>
> 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.
>
> Can we make it about not abbreviating build command lines, instead of
> maximal verbosity?  For example, enabling more warnings might make a
> compiler produce more verbose output, but it isn't the goal of this
> requirement.  Similarly, enabling compiler tracing might make a
> compiler produce more verbose output, and some people might even like
> that, but I don't believe that was the goal of this policy
> requirement.

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.  With
your example of compiler warnings, it's going to depend on whether a
given class of warnings is ever useful for finding and fixing bugs, and
this will depend on the programming language(s) and build system(s).
The maintainer will need to decide whether to include these, but it's
useful for Policy to tell them to err on the side of inclusion.

So how about making three changes:

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.

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.

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.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


Reply to: