Re: Proposed release goal: fix debian/rules build-arch
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/
Reply to: