Debian Bug report logs - #544844
rules.tiny doesn't use policy-mandated CFLAGS

version graph

Package: debhelper; Maintainer for debhelper is Debhelper Maintainers <debhelper-devel@lists.alioth.debian.org>; Source for debhelper is src:debhelper.

Reported by: Steve Langasek <vorlon@debian.org>

Date: Thu, 3 Sep 2009 10:00:02 UTC

Severity: important

Found in versions debhelper/7.3.15, debhelper/8.1.2

Fixed in version debhelper/8.9.0

Done: Joey Hess <joeyh@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Thu, 03 Sep 2009 10:00:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
New Bug report received and forwarded. Copy sent to Joey Hess <joeyh@debian.org>. (Thu, 03 Sep 2009 10:00:16 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: rules.tiny doesn't use policy-mandated CFLAGS
Date: Thu, 03 Sep 2009 02:47:34 -0700
Package: debhelper
Version: 7.3.15
Severity: important

Nothing in a standard dh build (neither dh_auto_configure nor dh_auto_build)
appears to ensure that the standard CFLAGS, "-g -O2", are passed to the
upstream build system by default.  This means that packages built with
"./debian/rules foo" (instead of via dpkg-buildpackage) are not policy
compliant in the general case unless the maintainer adds this boilerplate to
debian/rules themselves.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages debhelper depends on:
ii  binutils              2.19.51.20090805-1 The GNU assembler, linker and bina
ii  dpkg-dev              1.15.3.1           Debian package development tools
ii  file                  5.03-1             Determines file type using "magic"
ii  html2text             1.3.2a-14          advanced HTML to text converter
ii  man-db                2.5.5-3            on-line manual pager
ii  perl                  5.10.0-25          Larry Wall's Practical Extraction 
ii  perl-base             5.10.0-25          minimal Perl system
ii  po-debconf            1.0.16             tool for managing templates file t

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make                       0.48       tool that converts source archives

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#544844; Package debhelper. (Thu, 03 Sep 2009 18:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. (Thu, 03 Sep 2009 18:15:04 GMT) Full text and rfc822 format available.

Message #10 received at 544844@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: Steve Langasek <vorlon@debian.org>, 544844@bugs.debian.org
Subject: Re: Bug#544844: rules.tiny doesn't use policy-mandated CFLAGS
Date: Thu, 3 Sep 2009 14:03:30 -0400
[Message part 1 (text/plain, inline)]
Steve Langasek wrote:
> Nothing in a standard dh build (neither dh_auto_configure nor dh_auto_build)
> appears to ensure that the standard CFLAGS, "-g -O2", are passed to the
> upstream build system by default.  This means that packages built with
> "./debian/rules foo" (instead of via dpkg-buildpackage) are not policy
> compliant in the general case unless the maintainer adds this boilerplate to
> debian/rules themselves.

Debian needs to decide either:

A. The variable settings added to dpkg-buildpackage were a bad idea,
   both because they may override settings that individual package
   build systems more carefully tune, and because they make it
   impossible to be sure that building a package w/o dpkg-buildpackage
   will be policy compliant.

B. Building a package with dpkg-buildpackage is the only way anyone
   should do it anymore.

If A is the case, then dpkg-buildpackage should be fixed, and the first
part of A would seem to argue against adding additional variable setting to
debhelper.

If B is the case, then nothing is broken[1]; no debhelper changes needed.

If Debian cannot come to a decision about this[2], than option B seems
destined to win by default.

So I don't see how this is a debhelper bug. I can see how you might want
to use debhelper as a stopgap to prevent part of the problem, but
debhelper's purpose is not to work around questionable design choices in
dpkg-buildpackage by introducing yet more of the same dubious global
variable setting that got us here in the first place.

-- 
see shy jo

[1] Except for the unknown set of packages that have a Makefile
    containing CFLAGS?=something else, that have not been recompiled
    since the dpkg-buildpackage change.
[2] See thread at
    http://lists.debian.org/debian-devel/2009/03/msg00732.html and
    http://lists.debian.org/debian-devel/2009/05/msg00044.html ; BTW
    I'm having a hard time reconciling this bug report with messages
    like http://lists.debian.org/debian-devel/2009/05/msg00351.html
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Mon, 07 Sep 2009 20:18:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Mon, 07 Sep 2009 20:18:05 GMT) Full text and rfc822 format available.

Message #15 received at 544844@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: 544844@bugs.debian.org
Subject: Re: Bug#544844: rules.tiny doesn't use policy-mandated CFLAGS
Date: Mon, 7 Sep 2009 13:15:54 -0700
[Message part 1 (text/plain, inline)]
On Thu, Sep 03, 2009 at 02:03:30PM -0400, Joey Hess wrote:
> Debian needs to decide either:

> A. The variable settings added to dpkg-buildpackage were a bad idea,
>    both because they may override settings that individual package
>    build systems more carefully tune, and because they make it
>    impossible to be sure that building a package w/o dpkg-buildpackage
>    will be policy compliant.

> B. Building a package with dpkg-buildpackage is the only way anyone
>    should do it anymore.

> If A is the case, then dpkg-buildpackage should be fixed, and the first
> part of A would seem to argue against adding additional variable setting to
> debhelper.

My understanding is that the dpkg maintainers have already decided in favor
of A.

  The only one I can see being problematic is the build flags one, there
  might be packages that have started assuming dpkg-buildpackage will
  set the flags, so they might fail or misbuild once it stops doing so.

  http://lists.debian.org/debian-dpkg/2009/09/msg00015.html

My impression was that this is consistent with the outcome of the mailing
list discussions as well.

As for it being a bad idea because it overrides tuned settings from
individual package build systems:  much of the problem with
dpkg-buildpackage setting the flags was that they were being passed into
debian/rules by the caller.  I think this problem goes away if it's being
done via dh, if nothing else because the exceptional cases can use override
rules to ignore the flags if their upstream build systems have special
requirements.

> So I don't see how this is a debhelper bug.

It's a bug that the rules.tiny example isn't policy-compliant.  I have to
both declare the CFLAGS variable and add an override_dh_auto_configure rule
to get fully policy-compliant behavior.  The defaults should be optimized
for the common case, i.e., setting CFLAGS to -g {-O2,-O0} if not otherwise
set and passing CFLAGS to ./configure and/or make if not otherwise
overridden.

> [2] See thread at
>     http://lists.debian.org/debian-devel/2009/03/msg00732.html and
>     http://lists.debian.org/debian-devel/2009/05/msg00044.html

I've drawn a different conclusion from those threads, I guess; especially
from the mail, where Guillem opines that having dpkg-buildpackage set the
variables was a bad idea.

> ; BTW I'm having a hard time reconciling this bug report with messages
>     like http://lists.debian.org/debian-devel/2009/05/msg00351.html

Heh; I did talk about *additional* environment variables there, i.e., I'm
drawing a distinction between the policy-mandated build options and other
options that a distro or a site might like to apply to all packages when
rebuilding.  By my reading, setting -g -O2 is the package's responsibility
under policy (at least for the moment).

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#544844; Package debhelper. (Tue, 08 Sep 2009 19:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. (Tue, 08 Sep 2009 19:57:03 GMT) Full text and rfc822 format available.

Message #20 received at 544844@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: 544844@bugs.debian.org
Subject: Re: Bug#544844: rules.tiny doesn't use policy-mandated CFLAGS
Date: Tue, 8 Sep 2009 15:46:55 -0400
[Message part 1 (text/plain, inline)]
Steve Langasek wrote:
> My understanding is that the dpkg maintainers have already decided in favor
> of A.
> 
>   The only one I can see being problematic is the build flags one, there
>   might be packages that have started assuming dpkg-buildpackage will
>   set the flags, so they might fail or misbuild once it stops doing so.
> 
>   http://lists.debian.org/debian-dpkg/2009/09/msg00015.html
> 
> My impression was that this is consistent with the outcome of the mailing
> list discussions as well.
> 
> As for it being a bad idea because it overrides tuned settings from
> individual package build systems:  much of the problem with
> dpkg-buildpackage setting the flags was that they were being passed into
> debian/rules by the caller.  I think this problem goes away if it's being
> done via dh, if nothing else because the exceptional cases can use override
> rules to ignore the flags if their upstream build systems have special
> requirements.

I feel that if dh_auto_configure/build is going to provide a default CFLAGS
setting, this will need to wait for the v9 compatability level.
Otherwise there is the risk of breakage.

I am still, though, not convinced this is within debhelper's scope.
There is something to be said for fixing upstream Makefiles to use -O2 -g.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Wed, 09 Sep 2009 18:57:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Wed, 09 Sep 2009 18:57:06 GMT) Full text and rfc822 format available.

Message #25 received at 544844@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: 544844@bugs.debian.org
Subject: Re: Bug#544844: rules.tiny doesn't use policy-mandated CFLAGS
Date: Wed, 9 Sep 2009 11:54:51 -0700
[Message part 1 (text/plain, inline)]
On Tue, Sep 08, 2009 at 03:46:55PM -0400, Joey Hess wrote:
> I feel that if dh_auto_configure/build is going to provide a default CFLAGS
> setting, this will need to wait for the v9 compatability level.
> Otherwise there is the risk of breakage.

OK.

> I am still, though, not convinced this is within debhelper's scope.
> There is something to be said for fixing upstream Makefiles to use -O2 -g.

Upstream Makefiles aren't going to honor DEB_BUILD_OPTIONS=noopt...

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Sat, 20 Feb 2010 23:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Marcelo E. Magallón <mmagallo@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Sat, 20 Feb 2010 23:36:03 GMT) Full text and rfc822 format available.

Message #30 received at 544844@bugs.debian.org (full text, mbox):

From: Marcelo E. Magallón <mmagallo@debian.org>
To: 544844@bugs.debian.org
Subject: Re: doesn't use policy-mandated CFLAGS
Date: Sat, 20 Feb 2010 17:32:37 -0600
[Message part 1 (text/plain, inline)]
Hi,

 For unrelated reasons I was looking at the example files
 provided by debhelper and I noticed
 /usr/share/doc/debhelper/examples/rules.tiny.  My first hunch
 was that debhelper incorporates:

4.9.1. `debian/rules' and `DEB_BUILD_OPTIONS'
---------------------------------------------

    Supporting the standardized environment variable `DEB_BUILD_OPTIONS'
    is recommended.  [...]

    noopt
         The presence of this tag means that the package should be
         compiled with a minimum of optimization.  For C programs, it is
         best to add `-O0' to `CFLAGS' (although this is usually the
         default).  Some programs might fail to build or run at this level
         of optimization; it may be necessary to use `-O1', for example.

 mostly because it already pays attention to that environment
 variable wrt to parallel, nostrip and nocheck.

 Since I didn't find any support for it, I went ahead and wrote a
 proof-of-concept patch (attached).  Examining a small sample of
 source packages indicates that this idiom is currently in use:

 override_dh_auto_configure:
       dh_auto_configure -- CFLAGS="$(CFLAGS)"

 The patch supports this; it examines the arguments to dh_auto_*
 and adds CFLAGS only if it doesn't find something matching
 CFLAGS=.  It does NOT pay attention to the environment, which
 might or might not be a problem wrt this:

 http://lists.debian.org/debian-devel/2009/05/msg00044.html

 It certainly is a problem for tiny-like debian/rules.

 Since the implementation is at the Buildsystem level, it passes
 extra arguments to configure (autoconf) and make (makefile),
 i.e.:

   ./configure --other-options "CFLAGS=-g -Wall -O2"
   make "CFLAGS=-g -Wall -O2"

 Other Buildsystems require probably similar implementations.
 The behaviour is such that it only provides defaults (that
 follow Debian Policy's recommendations) and are easy to
 override.  It's not easy to entirely disable, though.

 The alternative solution is NOT to mess with the command line
 and instead place the values in the environment of the child
 process (configure, make, ...).  But in the case of makefiles
 like those generated by autotools (and other makefiles commonly
 seen in the wild) this wouldn't have any effect.

 Last but not least, CXXFLAGS should receive a similar treatment.

 Thoughts?

 Marcelo
[0001-Add-support-for-DEB_BUILD_OPTIONS-noopt.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#544844; Package debhelper. (Thu, 13 May 2010 00:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. (Thu, 13 May 2010 00:03:03 GMT) Full text and rfc822 format available.

Message #35 received at 544844@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: Marcelo E. Magallón <mmagallo@debian.org>, 544844@bugs.debian.org
Subject: Re: Bug#544844: doesn't use policy-mandated CFLAGS
Date: Wed, 12 May 2010 19:58:13 -0400
[Message part 1 (text/plain, inline)]
Marcelo E. Magallón wrote:
>  Since I didn't find any support for it, I went ahead and wrote a
>  proof-of-concept patch (attached).  Examining a small sample of
>  source packages indicates that this idiom is currently in use:
> 
>  override_dh_auto_configure:
>        dh_auto_configure -- CFLAGS="$(CFLAGS)"
> 
>  The patch supports this; it examines the arguments to dh_auto_*
>  and adds CFLAGS only if it doesn't find something matching
>  CFLAGS=.  It does NOT pay attention to the environment, which
>  might or might not be a problem wrt this:
> 
>  http://lists.debian.org/debian-devel/2009/05/msg00044.html
> 
>  It certainly is a problem for tiny-like debian/rules.

I think the environment definitely needs to override it.

>  Since the implementation is at the Buildsystem level, it passes
>  extra arguments to configure (autoconf) and make (makefile),
>  i.e.:
> 
>    ./configure --other-options "CFLAGS=-g -Wall -O2"
>    make "CFLAGS=-g -Wall -O2"
> 
>  Other Buildsystems require probably similar implementations.

Yes, and since using default CFLAGS settings need to be enabled by
setting v8 compat mode, all the buildsystems need to be changed at
once, or stragglers would have to wait for v9.

(Setting CFLAGS="-g -O0" for DEB_BUILD_OPTIONS=noopt does *not* need
v8 mode, it's acceptable if it breaks some obscure packages.)


I'm not sure how all this ties in with the new dpkg-buildflags command.
The right thing might be for debhelper to use dpkg-buildflags to get
default (and configurable) values.

  * Introduce a new script called dpkg-buildflags: its purpose is to retrieve
    compilation flags and it should be used within debian/rules to pass
    the right compilation flags to the build process. dpkg-builpackage still
    exports them to not break packages currently relying on them but packages
    should now start using dpkg-buildflags instead. Closes: #560070

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Fri, 28 May 2010 10:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Fri, 28 May 2010 10:24:04 GMT) Full text and rfc822 format available.

Message #40 received at 544844@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: Marcelo E. Magallón <mmagallo@debian.org>, 544844@bugs.debian.org, vorlon@debian.org
Subject: Re: Bug#544844: doesn't use policy-mandated CFLAGS
Date: Fri, 28 May 2010 12:21:26 +0200
Hi,

On Wed, 12 May 2010, Joey Hess wrote:
> I'm not sure how all this ties in with the new dpkg-buildflags command.
> The right thing might be for debhelper to use dpkg-buildflags to get
> default (and configurable) values.
> 
>   * Introduce a new script called dpkg-buildflags: its purpose is to retrieve
>     compilation flags and it should be used within debian/rules to pass
>     the right compilation flags to the build process. dpkg-builpackage still
>     exports them to not break packages currently relying on them but packages
>     should now start using dpkg-buildflags instead. Closes: #560070

I was about to file a bug so that debhelper start using dpkg-buildflags
and I came across this bug.

I agree with Steve that debhelper should really set up the environment
in dh_auto_configure and dh_build. I'm not sure what's the best way to do
that integration however (not being an autoconf expert).

At the very least, I suggest that you export the variables that
dpkg-buildpackage is exporting if they are not already set. That way, the
day when dpkg-buildpackage stops setting them all packages using
tiny rules files would not break. (You can even use Dpkg::BuildFlags
directly instead of dpkg-buildflags if you want to avoid some perl forks)

But maybe there's a cleaner interface to enforce build flags that involves
only changes at the ./configure stage?

I guess the analysis needs to be done for each of the build system that dh
currently supports.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Wed, 14 Jul 2010 18:33:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Wed, 14 Jul 2010 18:33:06 GMT) Full text and rfc822 format available.

Message #45 received at 544844@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Guillem Jover <guillem@debian.org>, 560070-submitter@bugs.debian.org, Ian Jackson <Ian.Jackson@eu.citrix.com>, 544844@bugs.debian.org
Subject: Re: Bug#560070: dpkg-buildpackage and LDFLAGS etc.
Date: Wed, 14 Jul 2010 13:31:12 -0500
Jonathan Nieder wrote:

> Isn’t that a kind of question for the release team to decide?

To clarify: if you are worried about debian/rules as produced
by e.g. dh_make, that is a different story; I can understand
holding off until debhelper learns to do something reasonable with
DEB_BUILD_OPTIONS=noopt.  And yes, that might mean waiting until
squeeze+1.

It would be nice to know what would break if dpkg-dev stopped
exporting CFLAGS.  Is there someone out there with hardware capable of
quickly rebuilding some representative subset of the archive to
determine that?

Sorry for the noise,
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Tue, 27 Jul 2010 06:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Tue, 27 Jul 2010 06:36:03 GMT) Full text and rfc822 format available.

Message #50 received at 544844@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Guillem Jover <guillem@debian.org>, 560070-submitter@bugs.debian.org, Ian Jackson <Ian.Jackson@eu.citrix.com>, 544844@bugs.debian.org
Subject: Re: Bug#560070: dpkg-buildpackage and LDFLAGS etc.
Date: Tue, 27 Jul 2010 08:33:31 +0200
Hi,

On Wed, 14 Jul 2010, Jonathan Nieder wrote:
> It would be nice to know what would break if dpkg-dev stopped
> exporting CFLAGS.  Is there someone out there with hardware capable of
> quickly rebuilding some representative subset of the archive to
> determine that?

Lucas Nussbaum has access to Grid5000 and regularly does full rebuilds.
Feel free to cooperate with him to gather any useful information.

But be aware that not all failures are catched at build time.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Tue, 27 Jul 2010 12:57:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Tue, 27 Jul 2010 12:57:05 GMT) Full text and rfc822 format available.

Message #55 received at 544844@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Raphael Hertzog <hertzog@debian.org>, 560070-quiet@bugs.debian.org
Cc: Jonathan Nieder <jrnieder@gmail.com>, Guillem Jover <guillem@debian.org>, 560070-submitter@bugs.debian.org, Ian Jackson <Ian.Jackson@eu.citrix.com>, 544844@bugs.debian.org
Subject: Re: Bug#560070: dpkg-buildpackage and LDFLAGS etc.o
Date: Tue, 27 Jul 2010 14:54:13 +0200
On Tue, Jul 27, 2010 at 08:33:31AM +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Wed, 14 Jul 2010, Jonathan Nieder wrote:
> > It would be nice to know what would break if dpkg-dev stopped
> > exporting CFLAGS.  Is there someone out there with hardware capable of
> > quickly rebuilding some representative subset of the archive to
> > determine that?
> 
> Lucas Nussbaum has access to Grid5000 and regularly does full rebuilds.
> Feel free to cooperate with him to gather any useful information.
> 
> But be aware that not all failures are catched at build time.

This also all true for the current situation. The bugs caused by exporting
CFLAGS that are not yet fixed are certainly in greater number than the bugs
that would be added by removing CFLAGS, even without considering that packages 
that depend on CFLAGS being set are not policy-compliant anyway.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Wed, 23 Mar 2011 07:48:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Wed, 23 Mar 2011 07:48:13 GMT) Full text and rfc822 format available.

Message #60 received at 544844@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: 544844@bugs.debian.org, joeyh@debian.org
Subject: Environment set by debhelper
Date: Wed, 23 Mar 2011 08:40:35 +0100
Hi Joey,

now that you're developing debhelper compat 9, it would be really nice
to deal with #544844.

To me it's clear that the consensus is in favor of supporting calling
debian/rules directly and I have taken steps in this direction while
working on dpkg-dev (created dpkg-buildflags, not adding vendor variable
in environment). It would be nice to have debhelper cope nicely with this
decision, otherwise you effectively force us to let dpkg-buildpackage set
the variables forever (or we break many more packages when we do the
change).

Replying more specifically to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544844#10 I think it's
clear the problem is not the usage of the enviroment variables, but the
fact that they had to be set by the caller of debian/rules. dh setting
the variables is OK because dh is called by debian/rules and thus a caller
of debian/rules does not have to provide anything in the environment.

Furthermore I realized that it would be nice for dh to setup a complete
environment at least when calling overrides targets so that we don't have
to put lots of boilerplate code in debian/rules:
- add if needed the dpkg-architecture variables (dpkg-architecture -l)
- add if needed the dpkg-buildflags variables (dpkg-buildflags --export=sh)
- set some convenience variables that we frequently compute with some
  custom shell command: source package name, first binary
  package name, version, upstream version

I say "add if needed" because the boiler-plate code is usually
FOO ?= $(shell) so you could set the variables only if they are
not already existing.

I hope it's enough to convince you. If not, please share your thoughts
on how we should go forward with this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Mon, 09 May 2011 09:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Mon, 09 May 2011 09:51:07 GMT) Full text and rfc822 format available.

Message #65 received at 544844@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: 544844@bugs.debian.org
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 560070@bugs.debian.org
Subject: Re: dpkg: please stop setting CFLAGS etc. environment variables
Date: Mon, 9 May 2011 04:48:35 -0500
Bill Allombert wrote:

> Hello Dpkg maintainers,
>
> Could you fix this issue soon so that it does not interfer with the
> release of Wheezy ?

Sounds good to me.  Raphaël, Joey, any thoughts?

-- >8 --
Subject: dpkg-buildpackage: do not export build flags

For over 10 years policy has required packages to set compiler flags
such as CFLAGS based on settings in DEB_BUILD_OPTIONS, not the values
inherited from dpkg-buildpackage.  Stop exporting such variables from
dpkg-buildpackage, so packages relying on the exported variables can
be caught early in the wheezy release cycle and we can be sure
packages build correctly when using debian/rules directly.

(Often a good way to set CFLAGS reasonably is with makefile snippets
like "CFLAGS := -Wall $(dpkg-buildflags --get CFLAGS)".)

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 man/dpkg-buildpackage.1      |    8 +++-----
 scripts/dpkg-buildpackage.pl |    8 --------
 2 files changed, 3 insertions(+), 13 deletions(-)

diff --git a/man/dpkg-buildpackage.1 b/man/dpkg-buildpackage.1
index 6460e51..698bff4 100644
--- a/man/dpkg-buildpackage.1
+++ b/man/dpkg-buildpackage.1
@@ -231,15 +231,13 @@ Show the version and exit.
 Even if \fBdpkg\-buildpackage\fP export some variables, \fBdebian/rules\fP
 should not rely on their presence and should instead use the
 respective interface to retrieve the needed values.
+Versions of \fBdpkg\-buildpackage\fP before 1.16.1 also exported
+compiler flags such as \fBCFLAGS\fP with values as returned
+by \fBdpkg\-buildflags\fP.
 .SS Variables set by dpkg-architecture
 \fBdpkg\-architecture\fP is called with the \fB\-a\fP and \fB\-t\fP
 parameters forwarded. Any variable that is output by its \fB\-s\fP
 option is integrated in the build environment.
-.SS Compiler flags
-The \fBCFLAGS\fP, \fBCXXFLAGS\fP, \fBFFLAGS\fP, \fBCPPFLAGS\fP
-and \fBLDFLAGS\fP environment variables are set to the values
-that \fBdpkg\-buildflags\fP returned. See its manual page for more
-information.
 .
 .SH BUGS
 It should be possible to specify spaces and shell metacharacters in
diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index aaea544..6eb241a 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -294,14 +294,6 @@ if (defined $parallel) {
     $build_opts->export();
 }
 
-my $build_flags = Dpkg::BuildFlags->new();
-$build_flags->load_config();
-foreach my $flag ($build_flags->list()) {
-    $ENV{$flag} = $build_flags->get($flag);
-    printf(_g("%s: export %s from dpkg-buildflags (origin: %s): %s\n"),
-	   $progname, $flag, $build_flags->get_origin($flag), $ENV{$flag});
-}
-
 my $cwd = cwd();
 my $dir = basename($cwd);
 
-- 
1.7.5.1





Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Mon, 09 May 2011 10:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Modestas Vainius <modax@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Mon, 09 May 2011 10:09:06 GMT) Full text and rfc822 format available.

Message #70 received at 544844@bugs.debian.org (full text, mbox):

From: Modestas Vainius <modax@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>, 544844@bugs.debian.org
Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 560070@bugs.debian.org
Subject: Re: Bug#544844: dpkg: please stop setting CFLAGS etc. environment variables
Date: Mon, 9 May 2011 13:05:15 +0300
[Message part 1 (text/plain, inline)]
Hello,

On pirmadienis 09 Gegužė 2011 12:48:35 Jonathan Nieder wrote:
> Bill Allombert wrote:
> > Hello Dpkg maintainers,
> > 
> > Could you fix this issue soon so that it does not interfer with the
> > release of Wheezy ?
> 
> Sounds good to me.  Raphaël, Joey, any thoughts?
> 
> -- >8 --
> Subject: dpkg-buildpackage: do not export build flags
> 
> For over 10 years policy has required packages to set compiler flags
> such as CFLAGS based on settings in DEB_BUILD_OPTIONS, not the values
> inherited from dpkg-buildpackage.  Stop exporting such variables from
> dpkg-buildpackage, so packages relying on the exported variables can
> be caught early in the wheezy release cycle and we can be sure
> packages build correctly when using debian/rules directly.

All examples of "minimal" dh rules have been recommending contrary all this 
time. Many packages will be broken unless this is dealt with in dh. 
Personally, I don't see why this can't be fixed in dh at new compat level 
(with an dh option to disable this auto-export of buildflags). 99,9% of 
packages will have to use dpkg-buildflags anyway so it is just pointless to 
have $(dpkg-buildflags --export=make) in each and every minimal dh rules file.

> (Often a good way to set CFLAGS reasonably is with makefile snippets
> like "CFLAGS := -Wall $(dpkg-buildflags --get CFLAGS)".)

I don't think this scales well. Something like $(dpkg-buildflags --
export=make) would be better to suggest. IMHO, project shall decide on clear 
recommendations how to proceed.

-- 
Modestas Vainius <modax@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Mon, 09 May 2011 10:39:32 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Mon, 09 May 2011 10:39:35 GMT) Full text and rfc822 format available.

Message #75 received at 544844@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Modestas Vainius <modax@debian.org>
Cc: 544844@bugs.debian.org, Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 560070@bugs.debian.org
Subject: Re: dpkg: please stop setting CFLAGS etc. environment variables
Date: Mon, 9 May 2011 05:34:31 -0500
Modestas Vainius wrote:

> All examples of "minimal" dh rules have been recommending contrary all this 
> time.

Also, where I said "policy has required" I should have said just
recommended.

> Many packages will be broken unless this is dealt with in dh. 
> Personally, I don't see why this can't be fixed in dh at new compat level 
> (with an dh option to disable this auto-export of buildflags). 99,9% of 
> packages will have to use dpkg-buildflags anyway so it is just pointless to 
> have $(dpkg-buildflags --export=make) in each and every minimal dh rules file.

Yes, I agree with you (hence the cc to Bug#560070).

Thinking more clearly about it, I wonder if dpkg-buildpackage has to
stop exporting those variables soon after all.  Maybe there could be
an option or envvar to stop exporting them (to help people test their
packages) and they could continue to be exported by default to support
old packages, just like the dpkg-architecture variables are.

The big downside: if the architecture variables are any indication of
what to expect, new maintainers would use the exported compiler flags.
It's too subtle.

In any scenario, I think debhelper is the place to make the first
step. :(




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Mon, 09 May 2011 10:39:41 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Mon, 09 May 2011 10:39:49 GMT) Full text and rfc822 format available.

Message #80 received at 544844@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Modestas Vainius <modax@debian.org>
Cc: 544844@bugs.debian.org, Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 560070@bugs.debian.org
Subject: Re: dpkg: please stop setting CFLAGS etc. environment variables
Date: Mon, 9 May 2011 05:37:00 -0500
Modestas Vainius wrote:

> I don't think this scales well. Something like $(dpkg-buildflags --
> export=make) would be better to suggest. IMHO, project shall decide on clear 
> recommendations how to proceed.

Side note: I don't know how to do that with GNU make, actually.
$(shell ...) works for one variable, but it converts newlines to
spaces.  In the spirit you suggest, the simplest way might be
something like

 configure-stamp:
	set -e; \
	eval "$$(dpkg-buildflags --export=sh)"; \
	CFLAGS="-Wall $$CFLAGS"; \
	./configure ...

In my own work I have been using

 CFLAGS := -Wall $(shell dpkg-buildflags --get CFLAGS)

which has some advantages over --export=sh:

 - it can be overridden on the "debian/rules" command line;
 - it allows me to easily pass the flags explicit on the configure
   command line instead of through the environment;
 - I can easily read and manipulate CFLAGS before passing it on;
 - it does not affect flags other than CFLAGS, so the effect
   gets well tested and the use case is obvious to me (unlike LDFLAGS
   et al).




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Mon, 09 May 2011 10:45:23 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Mon, 09 May 2011 10:45:29 GMT) Full text and rfc822 format available.

Message #85 received at 544844@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>, 560070@bugs.debian.org
Cc: Modestas Vainius <modax@debian.org>, 544844@bugs.debian.org, Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
Subject: Re: Bug#560070: dpkg: please stop setting CFLAGS etc. environment variables
Date: Mon, 9 May 2011 12:44:28 +0200
On Mon, 09 May 2011, Jonathan Nieder wrote:
> In any scenario, I think debhelper is the place to make the first
> step. :(

Yes. I did not really need a patch to rip out the environment variables,
what I need is some assurance that we're not reverting uselessly.

And for this, it would be nice to have an answer of how people should deal
with it in debhelper. So please prepare a patch for debhelper instead.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Mon, 09 May 2011 13:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Mon, 09 May 2011 13:33:04 GMT) Full text and rfc822 format available.

Message #90 received at 544844@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 544844@bugs.debian.org, 560070@bugs.debian.org
Subject: Re: dpkg: please stop setting CFLAGS etc. environment variables
Date: Mon, 9 May 2011 15:01:13 +0200
On Mon, May 09, 2011 at 04:48:35AM -0500, Jonathan Nieder wrote:
> diff --git a/man/dpkg-buildpackage.1 b/man/dpkg-buildpackage.1
> index 6460e51..698bff4 100644
> --- a/man/dpkg-buildpackage.1
> +++ b/man/dpkg-buildpackage.1
> @@ -231,15 +231,13 @@ Show the version and exit.
>  Even if \fBdpkg\-buildpackage\fP export some variables, \fBdebian/rules\fP
>  should not rely on their presence and should instead use the
>  respective interface to retrieve the needed values.
> +Versions of \fBdpkg\-buildpackage\fP before 1.16.1 also exported
> +compiler flags such as \fBCFLAGS\fP with values as returned
> +by \fBdpkg\-buildflags\fP.

I think you should state the range of version, e.g.

+Versions of \fBdpkg\-buildpackage\fP between 1.14.17 and 1.16.1 also exported
+compiler flags such as \fBCFLAGS\fP with values as returned
+by \fBdpkg\-buildflags\fP.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Sat, 14 May 2011 17:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Sat, 14 May 2011 17:21:03 GMT) Full text and rfc822 format available.

Message #95 received at 544844@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Debian Bug Tracking System <544844@bugs.debian.org>
Subject: Re: doesn't use policy-mandated CFLAGS
Date: Sat, 14 May 2011 19:16:21 +0200
Package: debhelper
Version: 8.1.2
Severity: normal
File: /usr/bin/dh

Hi,

I just stumbled on the same issue.

So what is the status of this now for debhelper? Will you add code in
dh to automatically initialize the variables with dpkg-buildflags if
they are unset?

I don't believe this needs a new compat level. If dpkg-buildpackage is
used those variables are still set so nothing will change there (which
preserves the behaviour on all buildds and for most users). Further
any package that sets the variables in their debian/rules will also
behave the same way. Only packages that do not set the variables in
debian/rules will suddenly behave the same wether called by
dpkg-buildpackage or debian/rules directly. So any package that breaks
by dh setting the variables would also already be broken when
dpkg-buildpackage is used. I would be that that number is 0.

And once dh sets the variables we could try not setting them in
dpkg-buildpackage and see what "breaks" without having all the dh using
package "break" (which we already know they would).

MfG
	Goswin

PS: Should someone help and provide patches for debhelper to do this?

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (666, 'unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-debian-xen-1 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages debhelper depends on:
ii  binutils               2.21.0.20110302-2 The GNU assembler, linker and bina
ii  dpkg-dev               1.15.8.10         Debian package development tools
ii  file                   5.04-5            Determines file type using "magic"
ii  html2text              1.3.2a-15         advanced HTML to text converter
ii  man-db                 2.5.7-4           on-line manual pager
ii  perl                   5.10.1-14         Larry Wall's Practical Extraction 
ii  perl-base              5.10.1-14         minimal Perl system
ii  po-debconf             1.0.16            tool for managing templates file t

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make                       0.55       tool that converts source archives

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Tue, 24 May 2011 19:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Tue, 24 May 2011 19:51:06 GMT) Full text and rfc822 format available.

Message #100 received at 544844@bugs.debian.org (full text, mbox):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Jonathan Nieder <jrnieder@gmail.com>, 560070@bugs.debian.org, Modestas Vainius <modax@debian.org>, 544844@bugs.debian.org
Subject: Re: Bug#560070: dpkg: please stop setting CFLAGS etc. environment variables
Date: Tue, 24 May 2011 21:46:26 +0200
On Mon, May 09, 2011 at 12:44:28PM +0200, Raphael Hertzog wrote:
> On Mon, 09 May 2011, Jonathan Nieder wrote:
> > In any scenario, I think debhelper is the place to make the first
> > step. :(
> 
> Yes. I did not really need a patch to rip out the environment variables,
> what I need is some assurance that we're not reverting uselessly.
> 
> And for this, it would be nice to have an answer of how people should deal
> with it in debhelper. So please prepare a patch for debhelper instead.

Joey Hess answer #10 to 544844 makes clear that fixing 560070 automatically fix
544844, so there is no patches to prepare nor any need to wait for debhelper.

fix this bug is enough
 
Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#544844; Package debhelper. (Tue, 14 Jun 2011 21:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. (Tue, 14 Jun 2011 21:03:04 GMT) Full text and rfc822 format available.

Message #105 received at 544844@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: 544844@bugs.debian.org
Subject: status of this bug
Date: Tue, 14 Jun 2011 17:02:18 -0400
[Message part 1 (text/plain, inline)]
What a flaming mess. I will never, ever, again let debhelper be the
workaround point for a bad decision, such as the one made by the dpkg
maintainers with forcing CFLAGS. Not without being paid at twice
my standard consulting rate at least. You have been warned.


So, my only interest now WRT this bug is to support dpkg-buildflags in
dh and dh_auto_* in a generic manner, and to support DEB_BUILD_OPTIONS=noopt
as best possible.

Since dpkg-buildflags could be used to set *any* variable, it does not
seem to make sense to add the build-system specific settings like
"./configure CFLAGS=foo", as Marcelo earlier prototyped. Avoiding that
build-system specific stuff and only setting environment variables (that
are not already set) means that supporting dpkg-buildflags will not
require a debhelper compat level change.

So, all that's needed is for dh (when running override targets, or just
generally) and dh_auto_* (for when not called by dh) to run
dpkg-buildflags --export, parse the shell formatted output, and shove it
into %ENV.

Now, as to DEB_BUILD_OPTIONS=noopt, probably the best way would for be
dh_auto_configure/dh_auto_build to support this by passing CFLAGS="-O0"
drectly to configure, etc. That way it would have the most chance
of turning on debugging build. But, that is in conflict with my
conclusions above. And perhaps the less perfect but much simpler way to
get debug builds is to use dpkg-buildflags to do it.


Note that I do not feel that these changes to debhelper will
make it safe to turn off dpkg-buildpackage's default CFLAGS stomping.
I think it's been well argued in this bug report by Bill A. that
it won't, and his analysis is probably still valid; also it's not
like everything uses dh.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Added tag(s) pending. Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. (Tue, 14 Jun 2011 21:27:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Sat, 18 Jun 2011 20:42:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Modestas Vainius <modax@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Sat, 18 Jun 2011 20:42:06 GMT) Full text and rfc822 format available.

Message #112 received at 544844@bugs.debian.org (full text, mbox):

From: Modestas Vainius <modax@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: 544844@bugs.debian.org, Raphael Hertzog <hertzog@debian.org>
Subject: Re: status of this bug
Date: Sat, 18 Jun 2011 23:39:50 +0300
[Message part 1 (text/plain, inline)]
Hello,

On trečiadienis 15 Birželis 2011 00:02:18 Joey Hess wrote:
> So, my only interest now WRT this bug is to support dpkg-buildflags in
> dh and dh_auto_* in a generic manner, and to support
> DEB_BUILD_OPTIONS=noopt as best possible.
> 
> Since dpkg-buildflags could be used to set *any* variable, it does not
> seem to make sense to add the build-system specific settings like
> "./configure CFLAGS=foo", as Marcelo earlier prototyped. Avoiding that
> build-system specific stuff and only setting environment variables (that
> are not already set)

I have some doubts about "(that are not already set)" part. Right now dpkg-
buildpackage is way more aggressive in this regard as it sets environment 
variables regardless if they already have been set or not. Relevant excerpt 
from dpkg-buildpackage code:

my $build_flags = Dpkg::BuildFlags->new();
$build_flags->load_config();
foreach my $flag ($build_flags->list()) {
    $ENV{$flag} = $build_flags->get($flag);
    printf(_g("%s: export %s from dpkg-buildflags (origin: %s): %s\n"),
       $progname, $flag, $build_flags->get_origin($flag), $ENV{$flag});
}

The upside of this aggressiveness is that sensitive environment variables, 
that might already have been set before debian/rules, will be overwritten and 
won't affect build of the package. I do understand that doing the same would 
break backwards compatibility in debhelper, but maybe that's a good idea to do 
for compat(9) or at least provide a dh/dh_auto_* option (e.g. --force-
buildflags) to give maintainers a choice to enable this. However, I very much 
prefer the former as in my opinion, most package maintainers will want (or 
assume) this behavior. Who would want random shell environment variables to 
affect package build? What's more, "clean environment" is even implied in 
examples of the Debian Policy ifself [1].

By the way, it's also a bit sad that:

export CFLAGS += -Wall

%:
	dh $@

will break. Fortunately, this can be replaced by DEB_CFLAGS_APPEND += -Wall. 
Maybe it's worthwhile to add this to the example of minimal rules?

[1] http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-
options (see how CFLAGS is handled)

> means that supporting dpkg-buildflags will not
> require a debhelper compat level change.
> 
> So, all that's needed is for dh (when running override targets, or just
> generally) and dh_auto_* (for when not called by dh) to run
> dpkg-buildflags --export, parse the shell formatted output, and shove it
> into %ENV.

I don't understand why you do not use Dpkg::BuildFlags directly. Its API is 
marked as stable (our $VERSION = "1.00" [2]). I'm CC'ing Raphael in case I'm 
suggesting something wrong.

[2] /usr/share/perl5/Dpkg/BuildFlags.pm:21

> Now, as to DEB_BUILD_OPTIONS=noopt, probably the best way would for be
> dh_auto_configure/dh_auto_build to support this by passing CFLAGS="-O0"
> drectly to configure, etc. That way it would have the most chance
> of turning on debugging build. But, that is in conflict with my
> conclusions above. And perhaps the less perfect but much simpler way to
> get debug builds is to use dpkg-buildflags to do it.

1) dpkg-buildflags already emits -O0 in case of DEB_BUILD_OPTIONS=noopt.
2) Why do you think that it is a good idea to *always* replace (s/-O\d+/-O0/) 
in flags even if they might have already been set by maintainer (+ given 
behaviour without noopt is different)? How is it backwards compatible?

The patch (0001) addressing Dpkg::BuildFlags usage, points 1) and 2) is 
attached. It does not implement that compat(9) suggestion of mine but it would 
be trivial to add.

-- 
Modestas Vainius <modestas@vainius.eu>
[0001-Use-Dpkg-BuildFlags-module-directly-in-set_buildflag.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Sat, 18 Jun 2011 20:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Modestas Vainius <modax@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Sat, 18 Jun 2011 20:51:06 GMT) Full text and rfc822 format available.

Message #117 received at 544844@bugs.debian.org (full text, mbox):

From: Modestas Vainius <modax@debian.org>
To: 544844@bugs.debian.org
Cc: Joey Hess <joeyh@debian.org>, Raphael Hertzog <hertzog@debian.org>
Subject: Re: Bug#544844: status of this bug
Date: Sat, 18 Jun 2011 23:48:55 +0300
[Message part 1 (text/plain, inline)]
Hello,

On šeštadienis 18 Birželis 2011 23:39:50 Modestas Vainius wrote:
> 
> The upside of this aggressiveness is that sensitive environment variables,
> that might already have been set before debian/rules, will be overwritten
> and won't affect build of the package. I do understand that doing the same
> would break backwards compatibility in debhelper, but maybe that's a good
> idea to do for compat(9) or at least provide a dh/dh_auto_* option (e.g.
> --force- buildflags) to give maintainers a choice to enable this. However,
> I very much prefer the former as in my opinion, most package maintainers
> will want (or assume) this behavior. Who would want random shell
> environment variables to affect package build? What's more, "clean
> environment" is even implied in examples of the Debian Policy ifself [1].

Ahh, when I wrote this compat(9) suggestion, I mostly had dh(1) in mind. 
Forced buildflags by default would not make much sense in the dh_auto_* 
context (and may be way more harmful than useful).

-- 
Modestas Vainius <modax@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#544844; Package debhelper. (Sun, 19 Jun 2011 18:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. (Sun, 19 Jun 2011 18:24:03 GMT) Full text and rfc822 format available.

Message #122 received at 544844@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: Modestas Vainius <modax@debian.org>
Cc: 544844@bugs.debian.org, Raphael Hertzog <hertzog@debian.org>
Subject: Re: status of this bug
Date: Sun, 19 Jun 2011 14:20:37 -0400
[Message part 1 (text/plain, inline)]
Modestas Vainius wrote:
> The upside of this aggressiveness is that sensitive environment variables, 
> that might already have been set before debian/rules, will be overwritten and 
> won't affect build of the package. I do understand that doing the same would 
> break backwards compatibility in debhelper, but maybe that's a good idea to do 
> for compat(9) or at least provide a dh/dh_auto_* option (e.g. --force-
> buildflags) to give maintainers a choice to enable this. However, I very much 
> prefer the former as in my opinion, most package maintainers will want (or 
> assume) this behavior. Who would want random shell environment variables to 
> affect package build? What's more, "clean environment" is even implied in 
> examples of the Debian Policy ifself [1].

debhelper cannot ensure a clean environment, it runs at the wrong level
of the build stack. Ie, the rules file has run, and had a chance to
set environment before debhelper runs, and it can't stomp on those
settings. So this is not debhelper's problem.

> By the way, it's also a bit sad that:
> 
> export CFLAGS += -Wall

> will break

debhelper could prepend dpkg-buildflags values to pre-existing
variables to support this. Assuming that CFLAGS="-O2 -Wall -O3" will
result in the maintainer's overridden -O3 taking effect.
I don't know that would be a good idea.

Note that this case won't break until dpkg-buildpackage removes the
forcing of the variables. I never said that this debhelper change could
solve the problems caused by dpkg-buildpackage forcing those variables.

> > So, all that's needed is for dh (when running override targets, or just
> > generally) and dh_auto_* (for when not called by dh) to run
> > dpkg-buildflags --export, parse the shell formatted output, and shove it
> > into %ENV.
> 
> I don't understand why you do not use Dpkg::BuildFlags directly. Its API is 
> marked as stable (our $VERSION = "1.00" [2]). I'm CC'ing Raphael in case I'm 
> suggesting something wrong.

Thanks, much better.

> [2] /usr/share/perl5/Dpkg/BuildFlags.pm:21
> 
> > Now, as to DEB_BUILD_OPTIONS=noopt, probably the best way would for be
> > dh_auto_configure/dh_auto_build to support this by passing CFLAGS="-O0"
> > drectly to configure, etc. That way it would have the most chance
> > of turning on debugging build. But, that is in conflict with my
> > conclusions above. And perhaps the less perfect but much simpler way to
> > get debug builds is to use dpkg-buildflags to do it.
> 
> 1) dpkg-buildflags already emits -O0 in case of DEB_BUILD_OPTIONS=noopt.

I thought I'd tried that and it didn't work. Ok.

> 2) Why do you think that it is a good idea to *always* replace (s/-O\d+/-O0/) 
> in flags even if they might have already been set by maintainer (+ given 
> behaviour without noopt is different)? How is it backwards compatible?

My feeling was it didn't matter to be backwards compatible here, the
code is only used for one-off debug builds so if it breaks you fix
things until it doesn't. But I certianly don't really care.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#544844; Package debhelper. (Sun, 19 Jun 2011 18:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. (Sun, 19 Jun 2011 18:27:03 GMT) Full text and rfc822 format available.

Message #127 received at 544844@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: Modestas Vainius <modax@debian.org>
Cc: 544844@bugs.debian.org, Raphael Hertzog <hertzog@debian.org>
Subject: Re: Bug#544844: status of this bug
Date: Sun, 19 Jun 2011 14:23:09 -0400
[Message part 1 (text/plain, inline)]
Modestas Vainius wrote:
> Hello,
> 
> On šeštadienis 18 Birželis 2011 23:39:50 Modestas Vainius wrote:
> > 
> > The upside of this aggressiveness is that sensitive environment variables,
> > that might already have been set before debian/rules, will be overwritten
> > and won't affect build of the package. I do understand that doing the same
> > would break backwards compatibility in debhelper, but maybe that's a good
> > idea to do for compat(9) or at least provide a dh/dh_auto_* option (e.g.
> > --force- buildflags) to give maintainers a choice to enable this. However,
> > I very much prefer the former as in my opinion, most package maintainers
> > will want (or assume) this behavior. Who would want random shell
> > environment variables to affect package build? What's more, "clean
> > environment" is even implied in examples of the Debian Policy ifself [1].
> 
> Ahh, when I wrote this compat(9) suggestion, I mostly had dh(1) in mind. 
> Forced buildflags by default would not make much sense in the dh_auto_* 
> context (and may be way more harmful than useful).

Even dh runs too late to deal with this.

(Also, I don't think policy has ever been about utterly sanitizing the
build environment. We have tools to do that, but we've gotten along
fine so far without PATH et al being forced by build tools.)

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Sun, 19 Jun 2011 18:36:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Sun, 19 Jun 2011 18:36:08 GMT) Full text and rfc822 format available.

Message #132 received at 544844@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: Modestas Vainius <modax@debian.org>, 544844@bugs.debian.org
Subject: Re: status of this bug
Date: Sun, 19 Jun 2011 20:33:08 +0200
Hi,

On Sun, 19 Jun 2011, Joey Hess wrote:
> > I don't understand why you do not use Dpkg::BuildFlags directly. Its API is 
> > marked as stable (our $VERSION = "1.00" [2]). I'm CC'ing Raphael in case I'm 
> > suggesting something wrong.
> 
> Thanks, much better.

Yes, it's ok to use Dpkg::BuildFlags.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Sun, 19 Jun 2011 21:18:14 GMT) Full text and rfc822 format available.

Acknowledgement sent to Modestas Vainius <modax@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Sun, 19 Jun 2011 21:18:38 GMT) Full text and rfc822 format available.

Message #137 received at 544844@bugs.debian.org (full text, mbox):

From: Modestas Vainius <modax@debian.org>
To: Joey Hess <joeyh@debian.org>
Cc: 544844@bugs.debian.org, Raphael Hertzog <hertzog@debian.org>
Subject: Re: status of this bug
Date: Mon, 20 Jun 2011 00:11:13 +0300
[Message part 1 (text/plain, inline)]
Hello,

On sekmadienis 19 Birželis 2011 21:20:37 Joey Hess wrote:
> Modestas Vainius wrote:
> > The upside of this aggressiveness is that sensitive environment
> > variables, that might already have been set before debian/rules, will be
> > overwritten and won't affect build of the package. I do understand that
> > doing the same would break backwards compatibility in debhelper, but
> > maybe that's a good idea to do for compat(9) or at least provide a
> > dh/dh_auto_* option (e.g. --force- buildflags) to give maintainers a
> > choice to enable this. However, I very much prefer the former as in my
> > opinion, most package maintainers will want (or assume) this behavior.
> > Who would want random shell environment variables to affect package
> > build? What's more, "clean environment" is even implied in examples of
> > the Debian Policy ifself [1].
> 
> debhelper cannot ensure a clean environment, it runs at the wrong level
> of the build stack. Ie, the rules file has run, and had a chance to
> set environment before debhelper runs, and it can't stomp on those
> settings. So this is not debhelper's problem.

Yeah, now I realized that...

> > By the way, it's also a bit sad that:
> > 
> > export CFLAGS += -Wall
> > 
> > will break
> 
> debhelper could prepend dpkg-buildflags values to pre-existing
> variables to support this. Assuming that CFLAGS="-O2 -Wall -O3" will
> result in the maintainer's overridden -O3 taking effect.
> I don't know that would be a good idea.

Prepending might work for CFLAGS, but it's probably pretty harmful for LDFLAGS 
unless maintainer has a way to disable prepending. As 'export LDFLAGS = ' 
wouldn't cut it with prepending in effect, a dh/dh_auto_* option would be 
needed.

On the other hand, it is really too bad that 'export DEB_LDFLAGS_{APPEND,SET} 
= ' will have no effect as long as dpkg-buildpackage keeps modifying 
environment. Both LDFLAGS and DEB_LDFLAGS_APPEND would need to be exported (or 
LDFLAGS unexported) in order to be compatible with both old agressive dpkg-
buildpackage and envvars-friendly dpkg-buildpackage. But this is not clean in 
my book (consider backports etc.).

In order to make `export DEB_*_{APPEND,SET}` work with both dpkg-
buildpackage's, I propose the attached patch (0002). The patch also tweaks 
documentation a bit wrt this topic. The patch should be safe but it will 
override VAR envvar if either of DEB_VAR_{APPEND,SET} is exported so I don't 
know if you want to add this to compat=9 (should be trivial to modify).

> Note that this case won't break until dpkg-buildpackage removes the
> forcing of the variables. I never said that this debhelper change could
> solve the problems caused by dpkg-buildpackage forcing those variables.

I understand that. But at least I no longer have to worry about putting 
explicit dpkg-buildflags calls in each rules file :-)

> > > So, all that's needed is for dh (when running override targets, or just
> > > generally) and dh_auto_* (for when not called by dh) to run
> > > dpkg-buildflags --export, parse the shell formatted output, and shove
> > > it into %ENV.
> > 
> > I don't understand why you do not use Dpkg::BuildFlags directly. Its API
> > is marked as stable (our $VERSION = "1.00" [2]). I'm CC'ing Raphael in
> > case I'm suggesting something wrong.
> 
> Thanks, much better.

My patch had a small bug wrt error handling (very unlikely case of 
Dpkg::BuildFlags failing to load). The patch (0001) is attached for the sake 
of perfection.

-- 
Modestas Vainius <modax@debian.org>
[0001-In-the-unlikely-case-Dpkg-BuildFlags-fails-don-t-do-.patch (text/x-patch, attachment)]
[0002-Always-respect-DEB_-flag-_-APPEND-SET-envvars.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Mon, 20 Jun 2011 06:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Mon, 20 Jun 2011 06:12:03 GMT) Full text and rfc822 format available.

Message #142 received at 544844@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Modestas Vainius <modax@debian.org>
Cc: Joey Hess <joeyh@debian.org>, 544844@bugs.debian.org
Subject: Re: status of this bug
Date: Mon, 20 Jun 2011 08:08:53 +0200
Hi,

On Mon, 20 Jun 2011, Modestas Vainius wrote:
> On the other hand, it is really too bad that 'export DEB_LDFLAGS_{APPEND,SET} 
> = ' will have no effect as long as dpkg-buildpackage keeps modifying 
> environment. Both LDFLAGS and DEB_LDFLAGS_APPEND would need to be exported (or 
> LDFLAGS unexported) in order to be compatible with both old agressive dpkg-
> buildpackage and envvars-friendly dpkg-buildpackage. But this is not clean in 
> my book (consider backports etc.).
> 
> In order to make `export DEB_*_{APPEND,SET}` work with both dpkg-
> buildpackage's, I propose the attached patch (0002). The patch also tweaks 
> documentation a bit wrt this topic. The patch should be safe but it will 
> override VAR envvar if either of DEB_VAR_{APPEND,SET} is exported so I don't 
> know if you want to add this to compat=9 (should be trivial to modify).

Hum, DEB_*_APPEND/SET were meant for users recompiling packages not really
for package maintainers. The logic was that dpkg-buildflags gives a set
of base flags and that the package can then tweak them.

And since Joey already decided to not override the variables if they are
already set, the correct way to tweak a value is to retrieve it in the
rules file and to reexport it in the environment. I don't see the need
for your supplementary patch.

That said for the sake of simplicity, it's probably a good idea
to improve dpkg-buildflags to support debian/buildflags.conf that would
be parsed after everything else (and that is clearly meant to be used by
the package maintainer).

Do you agree ?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Mon, 20 Jun 2011 08:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Modestas Vainius <modax@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Mon, 20 Jun 2011 08:57:16 GMT) Full text and rfc822 format available.

Message #147 received at 544844@bugs.debian.org (full text, mbox):

From: Modestas Vainius <modax@debian.org>
To: Raphael Hertzog <hertzog@debian.org>, 544844@bugs.debian.org
Cc: Joey Hess <joeyh@debian.org>
Subject: Re: Bug#544844: status of this bug
Date: Mon, 20 Jun 2011 11:53:50 +0300
[Message part 1 (text/plain, inline)]
Hello,

On pirmadienis 20 Birželis 2011 09:08:53 Raphael Hertzog wrote:
> Hi,
> 
> On Mon, 20 Jun 2011, Modestas Vainius wrote:
> > On the other hand, it is really too bad that 'export
> > DEB_LDFLAGS_{APPEND,SET} = ' will have no effect as long as
> > dpkg-buildpackage keeps modifying environment. Both LDFLAGS and
> > DEB_LDFLAGS_APPEND would need to be exported (or LDFLAGS unexported) in
> > order to be compatible with both old agressive dpkg- buildpackage and
> > envvars-friendly dpkg-buildpackage. But this is not clean in my book
> > (consider backports etc.).
> > 
> > In order to make `export DEB_*_{APPEND,SET}` work with both dpkg-
> > buildpackage's, I propose the attached patch (0002). The patch also
> > tweaks documentation a bit wrt this topic. The patch should be safe but
> > it will override VAR envvar if either of DEB_VAR_{APPEND,SET} is
> > exported so I don't know if you want to add this to compat=9 (should be
> > trivial to modify).
> 
> Hum, DEB_*_APPEND/SET were meant for users recompiling packages not really
> for package maintainers. The logic was that dpkg-buildflags gives a set
> of base flags and that the package can then tweak them.

Those intentions are not clear from the manual page.

> And since Joey already decided to not override the variables if they are
> already set, the correct way to tweak a value is to retrieve it in the
> rules file and to reexport it in the environment. I don't see the need
> for your supplementary patch.

Well, once again, that's not clear from the manual page. You can be pretty 
sure that some people wanting to avoid $(shell dpkg-buildflags ...) in rules 
(minimalism you know :-)) or to remember that "dpkg-buildflags ..." command or 
having no clue about dpkg-buildflags at all, may also think of a "smart way" 
to export those DEB_*_APPEND like I did. In my opinion, documentation has to 
be very clear on recommended practises. Personally, I think that those envvars 
are very easy target for abuse....

Anyway, then my patch is not really helping. Dh_Lib.pm part should be reverted 
and documentation should be fixed once we decide on the recommended practises. 
Having in mind #613046 , what's the recommended way to add -Wall to C(XX)FLAGS 
then? This should be put into dh(1).

> That said for the sake of simplicity, it's probably a good idea
> to improve dpkg-buildflags to support debian/buildflags.conf that would
> be parsed after everything else (and that is clearly meant to be used by
> the package maintainer).
> 
> Do you agree ?

I really don't think so. How many configuration files with alternating 
syntaxes do we need in debian/*? I have a feeling that debian/rules is 
starting to be become the least significant of them all. There should be the 
only good way (i.e. fewer possibilities for abuse) to do the same thing and it 
should be properly documented.

-- 
Modestas Vainius <modax@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Mon, 20 Jun 2011 12:03:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Mon, 20 Jun 2011 12:03:09 GMT) Full text and rfc822 format available.

Message #152 received at 544844@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Modestas Vainius <modax@debian.org>
Cc: 544844@bugs.debian.org, Joey Hess <joeyh@debian.org>
Subject: Re: Bug#544844: status of this bug
Date: Mon, 20 Jun 2011 14:01:58 +0200
On Mon, 20 Jun 2011, Modestas Vainius wrote:
> > Hum, DEB_*_APPEND/SET were meant for users recompiling packages not really
> > for package maintainers. The logic was that dpkg-buildflags gives a set
> > of base flags and that the package can then tweak them.
> 
> Those intentions are not clear from the manual page.

Yeah, I'll improve it.

> Anyway, then my patch is not really helping. Dh_Lib.pm part should be reverted 
> and documentation should be fixed once we decide on the recommended practises. 
> Having in mind #613046 , what's the recommended way to add -Wall to C(XX)FLAGS 
> then? This should be put into dh(1).

In the current situation, it's something like this:
export CFLAGS := -Wall $(shell dpkg-buildflags --get CFLAGS)

But I was suggesting to use debian/buildflags.conf so that any helper
script can get all the flags just with dpkg-buildflags without requiring
the kind of fallback logic that debhelper will use.

> > That said for the sake of simplicity, it's probably a good idea
> > to improve dpkg-buildflags to support debian/buildflags.conf that would
> > be parsed after everything else (and that is clearly meant to be used by
> > the package maintainer).
> > 
> > Do you agree ?
> 
> I really don't think so. How many configuration files with alternating 
> syntaxes do we need in debian/*? I have a feeling that debian/rules is 
> starting to be become the least significant of them all.

True. But that's IMO a good trend that dh and debhelper has set.

> There should be the only good way (i.e. fewer possibilities for abuse)
> to do the same thing and it should be properly documented.

And why wouldn't debian/buildflags.conf qualify for this? This would cover
98% of the needs and the 2% left would actually use debian/rules to do
more advanced changes.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Mon, 20 Jun 2011 20:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Modestas Vainius <modax@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Mon, 20 Jun 2011 20:27:03 GMT) Full text and rfc822 format available.

Message #157 received at 544844@bugs.debian.org (full text, mbox):

From: Modestas Vainius <modax@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 544844@bugs.debian.org, Joey Hess <joeyh@debian.org>
Subject: Re: Bug#544844: status of this bug
Date: Mon, 20 Jun 2011 23:26:03 +0300
[Message part 1 (text/plain, inline)]
Hello,

On pirmadienis 20 Birželis 2011 15:01:58 Raphael Hertzog wrote:
> > Anyway, then my patch is not really helping. Dh_Lib.pm part should be
> > reverted and documentation should be fixed once we decide on the
> > recommended practises. Having in mind #613046 , what's the recommended
> > way to add -Wall to C(XX)FLAGS then? This should be put into dh(1).
> 
> In the current situation, it's something like this:
> export CFLAGS := -Wall $(shell dpkg-buildflags --get CFLAGS)
> 
> But I was suggesting to use debian/buildflags.conf so that any helper
> script can get all the flags just with dpkg-buildflags without requiring
> the kind of fallback logic that debhelper will use.

Ok.

> > > That said for the sake of simplicity, it's probably a good idea
> > > to improve dpkg-buildflags to support debian/buildflags.conf that would
> > > be parsed after everything else (and that is clearly meant to be used
> > > by the package maintainer).
> > > 
> > > Do you agree ?
> > 
> > I really don't think so. How many configuration files with alternating
> > syntaxes do we need in debian/*? I have a feeling that debian/rules is
> > starting to be become the least significant of them all.
> 
> True. But that's IMO a good trend that dh and debhelper has set.

I disagree that this is a trend set by debhelper (or dh for that matter). dh 
uses debian/rules for configuration while debhelper uses small files for 
configuration of binary packages. Neither of current small files affect 
building of upstream source itself (which is what truly belongs to 
debian/rules imho).

Anyway, it may not be a bad idea if:

1) the name was better. .conf at the end is more like gbp.conf than anything 
else dpkg or debhelper currently uses. What's more I would rather prefer  
debian/buildenv, debian/env or something similar as a filename;

2) buildflags file was extendable and not limited to predefined set of flags. 
This way it could universably be used to export variables (everything in one 
place), i.e. fully configure build environment (e.g. like CC or CXX in rare 
cases). What's more, support for arch/platform specific buildflags files would 
be nice to have (and maintainers would probably expect this).

3) I'm not fond of the syntax but it is just a mere annoyance, nothing more 
severy. I would prefer something more familiar like:

$ cat debian/buildflags
# append
CFLAGS += -Wall
# set
CXXFLAGS = -g -O3
# this leaves no obvious way to prepend though

4) One of the downsides of this new functionality is that it's a bit too late. 
It is not in squeeze and wheezy is still far away. Therefore I expect its 
adpption to be rather slow. IMHO, it is kind of overkill to add dpkg-dev (>=) 
build-dependency just for this esp. if backports are planned. On the other 
hand, multiarch might indirectly help as then b-d needs to be added anyway.

> > There should be the only good way (i.e. fewer possibilities for abuse)
> > to do the same thing and it should be properly documented.
> 
> And why wouldn't debian/buildflags.conf qualify for this? This would cover
> 98% of the needs and the 2% left would actually use debian/rules to do
> more advanced changes.

So maintainer can still use:

export CFLAGS := -Wall $(shell dpkg-buildflags --get CFLAGS)

There you have a second way to do the same. So debian/buildflags has be 
designed as more attractive choice. lintian complaints might help too.

-- 
Modestas Vainius <modax@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Joey Hess <joeyh@debian.org>:
Bug#544844; Package debhelper. (Tue, 21 Jun 2011 06:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Joey Hess <joeyh@debian.org>. (Tue, 21 Jun 2011 06:33:03 GMT) Full text and rfc822 format available.

Message #162 received at 544844@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Modestas Vainius <modax@debian.org>
Cc: 544844@bugs.debian.org, Joey Hess <joeyh@debian.org>, debian-dpkg@lists.debian.org
Subject: Re: Bug#544844: status of this bug
Date: Tue, 21 Jun 2011 08:22:08 +0200
(Somehow I think we should move this sub-discussion somewhere else, ccing
debian-dpkg for a start, feel free to drop the bug when replying.
It would also be nice to have the feedback of others on this idea.)

On Mon, 20 Jun 2011, Modestas Vainius wrote:
> I disagree that this is a trend set by debhelper (or dh for that matter). dh 
> uses debian/rules for configuration while debhelper uses small files for 
> configuration of binary packages. Neither of current small files affect 
> building of upstream source itself (which is what truly belongs to 
> debian/rules imho).

So maybe that justifies using debian/source/buildflags rather than a file
directly in debian/ (just like debian/source/lintian-overrides). But up to
now debian/source/ was really for stuff affecting/concerning the .dsc so
I'm not sure.

> Anyway, it may not be a bad idea if:
> 
> 1) the name was better. .conf at the end is more like gbp.conf than anything 
> else dpkg or debhelper currently uses. What's more I would rather prefer  
> debian/buildenv, debian/env or something similar as a filename;

buildflags.conf would be consistent with the other files that the tool
uses though. But I'm ok to waive this in particular because of your next
point with the need to support arch/os specific overrides.

> 2) buildflags file was extendable and not limited to predefined set of flags. 
> This way it could universably be used to export variables (everything in one 
> place), i.e. fully configure build environment (e.g. like CC or CXX in rare 
> cases). What's more, support for arch/platform specific buildflags files would 
> be nice to have (and maintainers would probably expect this).

You can set new flags in the configuration files already (but you get a
warning). But dpkg-buildflags --list doesn't show them, it's specified
as the flags supported by the current vendor.

I agree that arch/os specific buildflags are sort of required if we want
to offer a way for maintainers to control the buildflags output by
dpkg-buildflags.

> 3) I'm not fond of the syntax but it is just a mere annoyance, nothing more 
> severy. I would prefer something more familiar like:
> 
> $ cat debian/buildflags
> # append
> CFLAGS += -Wall
> # set
> CXXFLAGS = -g -O3
> # this leaves no obvious way to prepend though

I can understand this but for this I think I'll keep the same syntax than
for the other files. I might add support for a "PREPEND" directive though.

> 4) One of the downsides of this new functionality is that it's a bit too late. 
> It is not in squeeze and wheezy is still far away. Therefore I expect its 
> adpption to be rather slow. IMHO, it is kind of overkill to add dpkg-dev (>=) 
> build-dependency just for this esp. if backports are planned. On the other 
> hand, multiarch might indirectly help as then b-d needs to be added anyway.

I think I will provide backports of dpkg because there are several new
functionalities that packages will want to adopt sooner rather than later
(both from dpkg and dpkg-dev).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Reply sent to Joey Hess <joeyh@debian.org>:
You have taken responsibility. (Fri, 24 Jun 2011 18:51:08 GMT) Full text and rfc822 format available.

Notification sent to Steve Langasek <vorlon@debian.org>:
Bug acknowledged by developer. (Fri, 24 Jun 2011 18:51:08 GMT) Full text and rfc822 format available.

Message #167 received at 544844-close@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: 544844-close@bugs.debian.org
Subject: Bug#544844: fixed in debhelper 8.9.0
Date: Fri, 24 Jun 2011 18:47:09 +0000
Source: debhelper
Source-Version: 8.9.0

We believe that the bug you reported is fixed in the latest version of
debhelper, which is due to be installed in the Debian FTP archive:

debhelper_8.9.0.dsc
  to main/d/debhelper/debhelper_8.9.0.dsc
debhelper_8.9.0.tar.gz
  to main/d/debhelper/debhelper_8.9.0.tar.gz
debhelper_8.9.0_all.deb
  to main/d/debhelper/debhelper_8.9.0_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 544844@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Joey Hess <joeyh@debian.org> (supplier of updated debhelper package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Fri, 24 Jun 2011 14:28:52 -0400
Source: debhelper
Binary: debhelper
Architecture: source all
Version: 8.9.0
Distribution: unstable
Urgency: low
Maintainer: Joey Hess <joeyh@debian.org>
Changed-By: Joey Hess <joeyh@debian.org>
Description: 
 debhelper  - helper programs for debian/rules
Closes: 541458 544844 627534 627737 628053 629139 630826
Changes: 
 debhelper (8.9.0) unstable; urgency=low
 .
   * dh: In v9, any standard rules file targets, including build-arch,
     build-indep, build, install, etc, can be defined in debian/rules
     without needing to explicitly tell make the dependencies between
     the targets. Closes: #629139
     (Thanks, Roger Leigh)
   * dh_auto_configure: In v9, does not include the source package name
     in --libexecdir when using autoconf. Closes: #541458
   * dh_auto_build, dh_auto_configure, dh: Set environment variables
     listed by dpkg-buildflags --export. Any environment variables that
     are already set to other values will not be changed.
     Closes: #544844
   * dh_movefiles: Optimise use of xargs. Closes: #627737
   * Correct docs about multiarch and v9. Closes: #630826
   * Fix example. Closes: #627534
   * Fix error message. Closes: #628053
   * dh_auto_configure: If there is a problem with cmake, display
     the CMakeCache.txt.
Checksums-Sha1: 
 04fc16f2247506059765f2031a7982269705020a 1568 debhelper_8.9.0.dsc
 a24326c4c2c0984783be408a90e857375f399c3a 383819 debhelper_8.9.0.tar.gz
 ca13253bfa8a960fd628a3fd3921eb679cba2d9d 559388 debhelper_8.9.0_all.deb
Checksums-Sha256: 
 d6fb5dfeaacadc5574c619560d950a623261ad229848a2bf1e02bad7ae89939b 1568 debhelper_8.9.0.dsc
 c9a1c2ceb4fcccd794199d738314f52cce9248ef24f360a1a101622df0b766c2 383819 debhelper_8.9.0.tar.gz
 35767a7c9937d103fddfcc7f810667509c26797150704a5f9ac511770d1fbf1f 559388 debhelper_8.9.0_all.deb
Files: 
 0dc2ec18b832d0aad04f680427d6d7c6 1568 devel optional debhelper_8.9.0.dsc
 0b3dbca729105330453f05498b71c288 383819 devel optional debhelper_8.9.0.tar.gz
 e4ccb25e81e935053d9aed5c0a9a66d2 559388 devel optional debhelper_8.9.0_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIVAwUBTgTYK8kQ2SIlEuPHAQhASA/8DAvEwz+nTdaJvJSZzpwqCrWYmClBtbdb
qdn0xbDBgGwHjbchoTGMX07HgWJWEC0SOBnGrtD8krUfHpOFJML+jgnsBjTEg5KW
A293CYxdHcXgWyhEEpbUbD++hmWlF2F4tWU1hWRg2y3pFf8sY1b7TIfv7RdETpsJ
h2FXW3a1EO1zCdc0EJPmcN3bZg+++ZKxjOLp9p9i1xwwd8sC2tz4cCkxdkNFLWsD
FZ+NQrDQLa4AT9s7lFUvb1VEaL/H7OXGioKP97eoj91DKUumMBmMuSTkEi5PLjGT
IBIwzdEdgwtdUi+4lnuz+dr7+Fbm7TVA6RyP6NLrLUXfCIO15vXyUdbwaNTJNnS9
xtH21+HWGq5W898CQcYXHegBiUQtt4vyfQF2N36UMTHPreih92P6ipnGtAWSup2P
jXAK2bDUEeyjbdHwR5CgfodCzNMVravJRuv/Z2vs91kwewSWKDNG9ctcjbhnbvTp
D/1GbFdVZd9OFfU+NXL8KpJwCmZOAHwo/E5nS373zb59KTz2287l0xx+TUJo5j7A
bclLjMZYUBnsMptaESozaEz4m9W8CN0TumSy/jqZBuMvTKRoJzP67IQv1RgYkFnc
ecI3a+a96fek6coyXpmpoIm5u09YuhlRpdQV9U1gigCD1dkCohhm3ITWiowrTqbw
CGqB7k2E8h8=
=/n9E
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Tue, 02 Aug 2011 07:34:23 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 06:28:45 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.