On 31/07/14 18:39, Kurt Roeckx wrote:
> On Thu, Jul 31, 2014 at 08:36:45AM +0100, Simon McVittie wrote:
> I think DH_VERBOSE does more than just pass
> --disable-silent-rules.
Yes, it still also does what it used to do, which is to make debhelper
echo each command it's going to run before it runs it. That's in the
same general category of "be more verbose, so that people trying to fix
a FTBFS they can't reproduce can see what the buildd is doing differently").
> You can also get the behaviour you want
> with setting V=1.
Yes, but I have to do either that or --disable-silent-rules as an extra
line in debian/rules in every Autotools package I touch, which is
somewhat at odds with "the Right Thing should be the default"; and
whenever a maintainer doesn't do that, it makes life harder for
build-log-checking, NMUers, and so on.
On that basis, several people have independently suggested that
debhelper should --disable-silent-rules by default. Joey was not willing
to do so by default, to avoid hiding warnings among a lot of noise in
developers' test builds, but said he wouldn't object to making
DH_VERBOSE have that extra side-effect.
I think it's a reasonable position to say that the right default for a
buildd, and the right default for a developer build, are different.
buildds are not accessible by random developers, so the build log is the
only information available to a developer wondering why their build
failed there - which is why it contains package versions, a summary of
toolchain versions, apt output, and all the other nice things that are
in the sbuild log.
I personally use a local sbuild to build my own packages for upload
(although I also do preliminary test builds outside sbuild if I expect
it to take several iterations) and I think a local sbuild is, on
balance, more like a buildd than it is like a test-build: you leave it
running noninteractively, and look at the log afterwards. That's most of
why this is a feature request on sbuild, not the buildd network.
(The other part is that if sbuild sets DH_VERBOSE, all architectures'
buildds will pick up that version eventually, whereas if it's per-buildd
configuration, AIUI I would have to ask the buildd maintainers for 13
architectures, plus an unknown number of unofficial ports, to set it up
individually :-)
For context please see #551463, #680686.
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
