Raphael Hertzog <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]