Raphael Hertzog <hert...@debian.org> writes:
> 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.
Wether dpkg-buildpackage calls build or the user call debian/rules
build manually makes no difference to the discussion. Policy says the
build targets needs B-D-I installed while current practice is that
build must work without B-D-I installed.
Think of it this way: The question is not about the interface for the
user to build package but about the interface of the source to allow
building. Wether dpkg-buildpackage invokes the build target or the
user makes no difference to the source.
>> 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.
Possibly as the last step. All packages could be build with a patched
dpkg-buildpackage, bugs could be filed, patches send, packages fixed
before anything has to be done to the official dpkg-buildpackage.
Although I favour breaking sources by changing the buildds as fast as
possible. If a maintainer bumps their standards version but fails to
follow it then let the source FTBFS.
>> 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.
I think Build-Options should only be for options. And the build-arch
target is not ment to be optional. Only for the transition there could
be a window of optionality. After that the target should just be a
MUST. Adding the target is trivialst and there is really no reason to
complicate the build tools by having it optional in the long run.
> 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.
And how is a per package Build-Options field supposed to do that? That
is clearly a per package choice and not a distribution choise. For
distribution choices the VENDOR approach from emdebian is more in line.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
