Re: New Build-Options field and build-arch option, please review
Raphael Hertzog <hertzog@debian.org> writes:
> On Fri, 11 Jul 2008, Russ Allbery wrote:
>> This doesn't make sense to me. The maintainer writes debian/rules; why
>> would they need to change Build-Options in debian/control to enable
>> anything about the build?
> Because they want that anyone can easily rebuild it with that option
> disabled?
That is already supported using the existing DEB_BUILD_OPTIONS mechanism.
I may be confused about your mental model here, but it seems like you're
moving rules about how the package is built from the package itself into
dpkg-buildpackage. If that's really what's happening, I think that is a
truly dreadful idea and strongly object. It should be possible to build
the package using whatever flags and options are the default by running
debian/rules build without involving dpkg-buildpackage at all, which
implies that the package should not be relying on dpkg-buildpackage to
provide compiler and linker flags. Those defaults should be in
debian/rules, just as they always have been for Debian packages.
If some set of flags, such as hardening, should be possible to easily
disable, this is exactly the same case as we have right now with
optimization and with stripping. The way to support that is to specify
another DEB_BUILD_OPTIONS flag which, if set, instructs the package to
modify its behavior accordingly. Furthermore, that allows the package
maintainer to provide more useful defaults specific to that package, such
as exactly the hardening flags that *that* package supports, rather than
some default (and possibly changing) set from dpkg-buildpackage.
DEB_BUILD_OPTIONS then stays clearly semantically separate from the
Build-Options-Supported field; the latter specifies which interfaces the
package supports, and the former is the way to actually *use* those
interfaces, with some exceptions for interfaces that can be used other
ways (such as build-arch/build-indep).
>> If the package maintainer wants the package to always be built with
>> those options, they should make that change directly in debian/rules,
>> not via this method.
> Why? (and it's not "always", it's by _default_)
See above. By moving the logic from debian/rules into dpkg-buildpackage,
we would be breaking a common workflow when working with packages.
Running debian/rules build in an unpacked source package to test would no
longer be a reasonable development step since you may get a completely
different compile than dpkg-buildpackage would give you.
I think the way that optimization and stripping are handled right now
works fairly well in practice, and I think we should be building on that
as a model, not replacing it with some entirely different method that
relies on additional external programs to wrap debian/rules.
The choice between always and by default can be handled using the existing
DEB_BUILD_OPTIONS mechanism just as optimization and stripping are now.
> I find it rather nice that we have a common way to enable this for all
> packages: add a hardening-wrapper to Build-Depends, add the option
> indicating which of the hardenings flags to enable, and you're done and
> it works for all packages.
Instead of doing that, you add hardening-wrapper to Build-Depends and
modify debian/rules to invoke it. The process is just as simple.
> Of course, you can also set the right variables in debian/rules directly
> but then you make it complex for anyone to disable those build options
> (for example to verify if a failure can be attributed to one of these
> hardening options).
Not if you implement a DEB_BUILD_OPTIONS flag at the same time. You can
then make hardening-wrapper trigger off of the DEB_BUILD_OPTIONS flag and
the package maintainer doesn't even have to handle it directly (very
similar to how debhelper packages let dh_strip handle DEB_BUILD_OPTIONS
for that flag).
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: