Re: Environment variables, debian/rules and dpkg-buildpackage
[ BCCed debian-dpkg for the proposed dpkg changes. ]
Hi!
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
anyway.
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
override.
,-- chk-flags --
#!/bin/sh
set -eu
regex="$@"
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
<http://lists.debian.org/debian-devel/2009/03/msg00920.html>.
* 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
instead).
* 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
`--
regards,
guillem
Reply to: