Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)
Hello Jonathan, On Mon 06 Aug 2018 at 06:24PM -0700, Jonathan Nieder wrote: > 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. This is an important point to bear in mind when working on Policy; thank you for noting it. > 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? These are the only examples that come to my mind at present, indeed. > [...] >> 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. After reading the message to which I'm replying, I am no longer confident in my previous opinion that recommending verbosity in general, and providing some examples of where verbosity is most important, is better than recommending verbosity in only specific cases (as you advocate). I would like to see opinions about this from people other than the few of us who have been writing to this bug. This bug will be closed on the next upload since we addressed the original submitter's main concern, but if you're still interested in driving this change to recommend verbosity in only specific cases, please do clone this bug, or file a new one (IMO the latter would be more useful at this point in the discussion, but I appreciate that it is more work). -- Sean Whitton signature.asc Description: PGP signature
Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)
control: tag -1 +pending Hello, On Tue 07 Aug 2018 at 09:26am +0200, Clément Hermann wrote: > IMO, s/maximally// would definitely fix the most pressing matter here, > that is, the fact that we have incompatible statements. I would > definitely be able to declare the go packages I maintain compliant, for > instance. > > However, regarding the rest of the discussion on this bug, I agree more > guidance to the maintainer as to what is expected would be nice. But > that is a separate issue, I think. > > How about resolving this one with this simple fix and opening a new one > to discuss making this paragraph better ? On Tue 07 Aug 2018 at 11:10am -0700, Jonathan Nieder wrote: > I don't believe s/maximally// changes the normative content --- it just > more clearly expresses what it already is saying. So I think a policy > editor can make that change without waiting for seconds. Thank you both. Applied in git. With regard to offering package maintainers more guidance as to how verbose builds should be, I'll leave it up to Jonathan to either clone this bug, or file a new one. (I'm not sure whether Jonathan feels it is possible to summarise the current discussion as the first message to a new bug, or whether things are still sufficiently unclear that all the context needs to be present.) -- Sean Whitton signature.asc Description: PGP signature
Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)
Hi, Clément Hermann wrote: > On 03/08/2018 04:23, Sean Whitton wrote: > > On Thu 02 Aug 2018 at 12:16PM +0800, Clément Hermann wrote: >>> "as verbose as reasonably possible" seems incompatible with "maximally >>> verbose >>> output", at least in some cases (golang packages come to mind). >>> >>> Would it be possible to clarify this ? >> >> Yes. Let's improve this. >> >> Would s/maximally// be sufficient? Or s/maximally/more/ ? > > IMO, s/maximally// would definitely fix the most pressing matter here, > that is, the fact that we have incompatible statements. I would > definitely be able to declare the go packages I maintain compliant, for > instance. > > However, regarding the rest of the discussion on this bug, I agree more > guidance to the maintainer as to what is expected would be nice. But > that is a separate issue, I think. Ah, thanks! Sorry to have misunderstood. I don't believe s/maximally// changes the normative content --- it just more clearly expresses what it already is saying. So I think a policy editor can make that change without waiting for seconds. Anyway, just in case, seconded. Thanks, Jonathan
Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)
Hi Sean, On Mon, Aug 06, 2018 at 06:04:02PM +0800, Sean Whitton wrote: > 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. those seem all very reasonable to me, thanks! -- cheers, Holger --- holger@(debian|reproducible-builds).org signature.asc Description: PGP signature
Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)
Hello, On 03/08/2018 04:23, Sean Whitton wrote: > Hello, > > On Thu 02 Aug 2018 at 12:16PM +0800, Clément Hermann wrote: > >> "as verbose as reasonably possible" seems incompatible with "maximally >> verbose >> output", at least in some cases (golang packages come to mind). >> >> Would it be possible to clarify this ? > > Yes. Let's improve this. > > Would s/maximally// be sufficient? Or s/maximally/more/ ? > IMO, s/maximally// would definitely fix the most pressing matter here, that is, the fact that we have incompatible statements. I would definitely be able to declare the go packages I maintain compliant, for instance. However, regarding the rest of the discussion on this bug, I agree more guidance to the maintainer as to what is expected would be nice. But that is a separate issue, I think. How about resolving this one with this simple fix and opening a new one to discuss making this paragraph better ? Cheers, nodens
Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)
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
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 signature.asc Description: PGP signature
Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)
Sean Whitton wrote: > On Thu 02 Aug 2018 at 12:16PM +0800, Clément Hermann wrote: >> "as verbose as reasonably possible" seems incompatible with "maximally >> verbose >> output", at least in some cases (golang packages come to mind). >> >> Would it be possible to clarify this ? > > Yes. Let's improve this. > > Would s/maximally// be sufficient? Or s/maximally/more/ ? I don't know a better way to say this, so I'll just say it: I am not feeling listened to. I am feeling talked past. No, that wouldn't be sufficient at all. I think some of that is inevitable in the rush to resolve policy bugs, but there are other ways to get this done that are less dismissive (for example, requesting a patch). If you'd like more detail from me, is there some appropriate place to discuss this in real time? I am jrnieder on freenode. Jonathan
Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)
Hi, Sean Whitton wrote: > On Wed 01 Aug 2018 at 10:47PM -0700, Jonathan Nieder wrote: >> Thanks for reporting. My understanding from >> https://bugs.debian.org/628515 is that the intention is >> >> - print out compiler driver command lines, so that compiler errors are >> closely preceded with the command that produced them >> >> - no need to print out command lines for tools like ld that are >> themselves invoked by the compiler driver, but do print out those >> command lines if you invoke them directly >> >> I don't think verbosity for the sake of verbosity was ever a goal >> here, so ideas for better wording would be very welcome. >> >> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628515;msg=30 >> I proposed wording along the lines of [... wording snipped ...] > IIRC my hope was to generalise the recommendation to apply to as many > different build systems as possible. For example, packages whose builds > do not involve any compilers and linkers. > > 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. Hope that helps, Jonathan
Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)
Hello Jonathan, On Wed 01 Aug 2018 at 10:47PM -0700, Jonathan Nieder wrote: > Thanks for reporting. My understanding from > https://bugs.debian.org/628515 is that the intention is > > - print out compiler driver command lines, so that compiler errors are > closely preceded with the command that produced them > > - no need to print out command lines for tools like ld that are > themselves invoked by the compiler driver, but do print out those > command lines if you invoke them directly > > I don't think verbosity for the sake of verbosity was ever a goal > here, so ideas for better wording would be very welcome. > > In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628515;msg=30 > I proposed wording along the lines of > > terse > > Compiler and linker commands used to build the package > should not be abbreviated in the log unless this > tag is supplied. > > Packages built with cmake, autotools, or > the Linux kernel build system can implement this by > passing the parameters V=1 and > VERBOSE=1 by default as arguments to > make and omitting them when the terse tag is > supplied. > > > I am not sure why this suggestion got generalized to "as verbose as > reasonably possible" in the patch that replaced it. IIRC my hope was to generalise the recommendation to apply to as many different build systems as possible. For example, packages whose builds do not involve any compilers and linkers. We could restore your text in a footnote or a "For example ..." paragraph? -- Sean Whitton signature.asc Description: PGP signature
Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)
Hello, On Thu 02 Aug 2018 at 12:16PM +0800, Clément Hermann wrote: > "as verbose as reasonably possible" seems incompatible with "maximally verbose > output", at least in some cases (golang packages come to mind). > > Would it be possible to clarify this ? Yes. Let's improve this. Would s/maximally// be sufficient? Or s/maximally/more/ ? -- Sean Whitton signature.asc Description: PGP signature
Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)
Hi, Clément Hermann wrote: > 4.9 states: > The package build should be as verbose as reasonably possible. > This means that ``debian/rules`` should pass to the commands it > invokes options that cause them to produce maximally verbose > output. > > "as verbose as reasonably possible" seems incompatible with "maximally verbose > output", at least in some cases (golang packages come to mind). > > Would it be possible to clarify this ? Thanks for reporting. My understanding from https://bugs.debian.org/628515 is that the intention is - print out compiler driver command lines, so that compiler errors are closely preceded with the command that produced them - no need to print out command lines for tools like ld that are themselves invoked by the compiler driver, but do print out those command lines if you invoke them directly I don't think verbosity for the sake of verbosity was ever a goal here, so ideas for better wording would be very welcome. In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628515;msg=30 I proposed wording along the lines of terse Compiler and linker commands used to build the package should not be abbreviated in the log unless this tag is supplied. Packages built with cmake, autotools, or the Linux kernel build system can implement this by passing the parameters V=1 and VERBOSE=1 by default as arguments to make and omitting them when the terse tag is supplied. I am not sure why this suggestion got generalized to "as verbose as reasonably possible" in the patch that replaced it. Thanks and hope that helps, Jonathan
Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)
Package: debian-policy Version: 4.2.0.0 Severity: normal Hi, 4.9 states: The package build should be as verbose as reasonably possible. This means that ``debian/rules`` should pass to the commands it invokes options that cause them to produce maximally verbose output. "as verbose as reasonably possible" seems incompatible with "maximally verbose output", at least in some cases (golang packages come to mind). Would it be possible to clarify this ? Cheers, -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debian-policy depends on: ii libjs-sphinxdoc 1.7.6-1 debian-policy recommends no packages. Versions of packages debian-policy suggests: ii doc-base 0.10.8 -- no debconf information
