[ 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 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
