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

Re: Environment variables, debian/rules and dpkg-buildpackage

[ BCCed debian-dpkg for the proposed dpkg changes. ]


On Fri, 2009-03-13 at 21:04:30 +0100, Raphael Hertzog wrote:
> we have an unfortunate situation where the practice in dpkg-buildpackage
> and the policy do not match fully.

Ok, had finally the time to read and think about this. I've to say first
of all that I've never quite liked dpkg-buildpackage as a way to set
distro-wide flags, and less so by doing it by default and kind of
deprecating debian/rules in the way. But at the time this got implemented
I didn't have the time to ponder about better alternatives or discuss
about it (although the makefile include crossed my mind at some point,
and we talked about it with Raphaël before he started this thread).
In retrospect I guess I should have chimed in on the initial discussion
or the subsequent complaints, but nothing that cannot be repaired now

I'll try to summarize the discussion (althought it might be biased to
my preferred option) and some facts, so that we can get to a conclusion:

* We'd like to have at least this overriding hierarchy (the
  implementation could be a bit more complex, but I think that's
  not important now, as this one already exposes problems in the
  dpkg-buildpackage proposal):

  - Distro defaults.
  - Site overrides over the above (can be partial filters).
  - Package overrides over the above (can be partial filters).
  - User overrides over the above (total overrides).

* dpkg-buildpackage currently sets the build flags through env vars.

* Lots of packages (roughly around 4k) do not honour env vars for build
  flags, as they follow the examples from policy (or dh-make and similar)
  and thus are setting them unconditionally, which env vars do not

,-- chk-flags --
set -eu
cd /srv/lintian.debian.org/laboratory/source/
ls | xargs -I% grep -H -l "$regex" %/debfiles/rules | wc -l

  ./chk-flags '^[^#]*\(CXX\|F\|CPP\|LD\|C\)FLAGS[[:space:]]*:\?='

* Thus lots of packages in the archive have to be modified anyway
  regardless of either solution (centralization through dpkg-buildpackage
  or makefile include). If we have to modify them, we can make them
  include a makefile. Adding such include line at the top of debian/rules
  should certainly imply less changes than the proposed changes in

* dpkg-buildpackage has been setting env vars for dpkg-architecture
  output for a long time (2001), but those flags are a bit different
  than the other build flags. First the example code in dh-make uses ?=
  which makes the env vars take preference, and they are (or should be)
  always initialized in the debian/rules file as recommended by
  dpkg-architecture(1). And second the *_BUILD_* ones should alway match
  the current system, and the *_HOST_* ones should be changed by
  changing the toolchain, so there's no reason to override them in the
  distro or packaging (if there's a need then dpkg should be fixed

* Externalizing the setup of the build flags means that debian/rules
  stops being a working standalone interface for building packages, as
  mandated by policy, and imposes an additional layer to rely on for
  building packages

* Setting system (distro and site) build vars through command line (or
  forced environment 'make -e') does not allow the pkg to override them,
  nor do partial filtering.

* Using 'make -e' is not really a good idea as it's not fine grained. So
  the correct solution when total override is desired is to set the
  vars via the command line.

* Setting system (distro and site) build vars through command line,
  implies we can only use limited make syntax for those vars.

* We can set the architecture and default flags (from policy) on the
  makefile to be included, and packagers will be able to do the change
  and fix any possible problems (progressive opt-in), but once it's
  included by all packages, then we can do system-wide default changes
  in the same we change toolchains (mass rebuild, bug filing, change
  when bug count goes down). The makefile has the advantage that the
  distro default can be temporarily changed for the mass build w/o
  needing to totally override the build flags.

So I think for next dpkg upload we should make dpkg-buildpackage stop
setting any flags by default, and switch the setting to go through the
command line arguments to override the package options instead of the
environment, so this would become the user override part. The DEB_VENDOR
env var should not be set either, and we should work on getting a
dpkg-vendor instead, before people try to start using the variable.

Then if we get consensus that this is the righ path, agree on the
makefile names (as once decided it will be a pain to change later on in
all packages), we'll need to ship the distro defaults file somewhere and
start fixing packages to include that makefile. The files could look
something like:

,-- /usr/share/dpkg/build-options.mk
# distro defaults
FOO := distro

-include /etc/dpkg/build-options.mk

,-- /etc/dpkg/build-options.mk
# site overrides
#FOO := site

,-- debian/rules
-include /usr/share/dpkg/build-options.mk

# package overrides
FOO := pkg

,-- command line
# user overrides
$ make -f debian/rules FOO=cmd


Reply to: