On Mon, 16 Feb 2009, Kari Pahula wrote: > Currently, Debian Policy doesn't match with the current practice in > section 7.7. > > > The Build-Depends-Indep and Build-Conflicts-Indep fields must be > > satisfied when any of the following targets is invoked: build, > > build-indep, binary and binary-indep. > > I know that people like to say that Policy should reflect reality, not > have wishful thinking (like in #178809). It's been tried before but > I'd like to try again to get a transition done to make reality into > what 7.7 says it is.
I don't know if you are aware, but there's lots of discussion already about this in various dpkg bug reports and in particular this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229357 This bug is on my radar and I certainly plan to fix it in the squeeze timeline but before we can clearly fix it, we need to come to a reasonable agreement about what constitutes the official interface to build Debian packages and how it should look like. We currently have an unfortunate divergence between dpkg-buildpackage and the policy that needs to be solved before we can tackle this problem seriously. > Now, option 1 (cold turkey): > > Make build-arch to be a mandatory target in debian/rules files in the > next policy version (3.9.0, already?). Any existing "build" targets > work, by necessity, correctly without having B-D-I installed, and a > debian/rules file could be fixed by adding one line: > build-arch: build > > Buildds would still call "debian/rules build" on anything that had a Note: buildd use dpkg-buildpackage so the change needs to be done in dpkg-buildpackage. > Option 2 (features field): > > Add a field called "Build-Features:" to debian/control and have it > contain a space separated list of tokens. Define "build-arch" as a > recognized value. Put that in .dsc. As with things like this, we'd > potentially get stuck with it forever, but it'd be the least invasive > thing to do and still get buildds to use build-arch. There'd be no > transition, other than getting sbuild patched. > > We could also change build-arch into a "should" feature and warn > anyone who didn't support build-arch and switch over to having it as a > "must" once everyone did it. It'd be easy to check for that, with > this. My current plan is to implement a Build-Options field but the expected use case for such a field are a bit too broad and it leads us to the discussion about how much "build customization" we should support and how that customization must be handled (and how we should mix choices of packagers, choices of user that rebuild the package, choices of the (derivative) distributions). Note the usage of standards-version to auto-enable some options is still possible even if we implement Build-Options. The first and main customization that users and derivatives distributions want is related to compiler options so that they can do hardened builds or optimized builds without having to hand-edit each and every package. We have integrated some changes during Lenny related to that but it can't deliver its potential if we don't change the policy to say that package must respect/use the compiler flags provided in the environment. Unfortunately, that change was merged/made in dpkg without much consultation of debian-policy and we're now stuck in a situation where the disagreement expressed afterwards would certainly lead to a refusal of a policy change going in that direction. On that topic I recently started to draft this wiki page, I hope it can help summarize the options and the issues with each approach and we can decide what direction we want to take. http://wiki.debian.org/Teams/Dpkg/DebianRules This wiki page is centered only on the topic of the preparation of the build environment but its outcome will obviously have some consequences on the decision we're going to take for the the build vs build-arch problem. At least because it will have implications on the implementation of Build-Options. (I'm not sure that this discussion will be very constructive at this stage because I wanted to get some more private feedback to better channel the discussion but let's see…) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org