Bug#489771: New Build-Options field and build-arch option, please review
On Wed, 10 Sep 2008, Bill Allombert wrote: People have noticed that and already requested that we can call arbitrary targets of debian/rules with all the proper initialization done precisely for test purpose during packaging work (see #477916). I must say, I really do not like this direction. debhelper and cdbs and similar sytsems are the places to provide this help where people want to use it, in my opinion. We have a lot of past experience with that and we have the compatibility level to handle smoothing transitions. (And to provide a way for people to never transition, I admit, and I see where that's the problem that you're solving, but I prefer that problem to the problems introduced by the instability of having the package build infrastructure change the input to the builds without coordination with the package.) I like to say I concurr with Russ. There are some much difference between packages that distributions wide default does not make sense. Such change would rather lead me to hardcode values of DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly. But more and more people want to be able to change distribution wide default: Emdebian wants to enable nodocs and nocheck by default, other want to be able to enable hardening options by default and I agree with them that official support for such a facility is desirable. See also #498355 and #498380 for such requests from Emdebian. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229357: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, 2008-09-11 at 08:46 +0200, Raphael Hertzog wrote: On Wed, 10 Sep 2008, Bill Allombert wrote: People have noticed that and already requested that we can call arbitrary targets of debian/rules with all the proper initialization done precisely for test purpose during packaging work (see #477916). I must say, I really do not like this direction. debhelper and cdbs and similar sytsems are the places to provide this help where people want to use it, in my opinion. The actual support will be implemented in debhelper - all that is needed is a consistent manner to pass the same options to debhelper across a range of packages. Packages then add extra support if necessary, e.g. if a package installs docs manually instead of using dh_installdocs, then those sections of debian/rules need to be either conditionally excluded: ifeq (,$(findstring nodocs,$(DEB_BUILD_OPTIONS))) install foo.1 debian/foo/usr/share/man/man1/ ... endif or redone for debhelper support via foo.install files, etc. After Lenny, I will be filing bugs for this support - at least for the packages used in Emdebian. We have a lot of past experience with that and we have the compatibility level to handle smoothing transitions. (And to provide a way for people to never transition, I admit, and I see where that's the problem that you're solving, but I prefer that problem to the problems introduced by the instability of having the package build infrastructure change the input to the builds without coordination with the package.) There has to be coordination with the package - the package needs to support the build option, either explicitly or via debhelper. All CDBS or any other layer needs to do is pass down the option to make it accessible to debhelper (usually via DEB_BUILD_OPTIONS). I like to say I concurr with Russ. There are some much difference between packages that distributions wide default does not make sense. On the contrary, there are clear divisions where distribution-wide build options do make sense. Raphael correctly identifies nodocs and nocheck as the current Emdebian distribution-wide build options. nodocs itself needs to be refined to allow for graded levels of documentation exclusion and other build options may change the build process itself - all under the control of the particular package. If the package does not understand the option, nothing happens. e.g. Emdebian needs nodocs (or something as broad) that drops everything, from README and TODO to changelog.gz and manpages during the build, rather than after downloading. Preferably, nodocs would also lead to the mandatory compression of copyright to save more space. It is not new for DEB_BUILD_OPTIONS to break Debian Policy - supporting a distribution-wide superset of options allows the use of the set to conform to Emdebian Policy etc. Other uses of options could use graduations so that examples are dropped but not the rest, or just manpages or just HTML docs etc. Dpkg Classes will help with graduations, as long as the distro can afford to remove the files *after* the package has been downloaded. But more and more people want to be able to change distribution wide default: Emdebian wants to enable nodocs and nocheck by default, other want to be able to enable hardening options by default and I agree with them that official support for such a facility is desirable. See also #498355 and #498380 for such requests from Emdebian. Note also that Ubuntu are interested in supporting distribution-wide build options. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Bug#489771: New Build-Options field and build-arch option, please review
Raphael Hertzog [EMAIL PROTECTED] writes: On Wed, 10 Sep 2008, Bill Allombert wrote: I like to say I concurr with Russ. There are some much difference between packages that distributions wide default does not make sense. Such change would rather lead me to hardcode values of DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly. But more and more people want to be able to change distribution wide default: Emdebian wants to enable nodocs and nocheck by default, other want to be able to enable hardening options by default and I agree with them that official support for such a facility is desirable. So they should set DEB_BUILD_OPTIONS in the environment. That's what it's for. I don't have any objections to that, or even to doing it via dpkg-buildpackage. My objection is specifically to having dpkg-buildpackage set a variety of environment variables *by default*, and then telling package maintainers that they should rely on those environment variables being set in the default case. That breaks the debian/rules interface and requires that all package builds go through dpkg-buildpackage. Having dpkg-buildpackage set environment variables in the non-default case like Emdebian is not a problem, since for Emdebian builds (for example) Emdebian can decide that using dpkg-buildpackage or setting the environment variables manually is required. There is no existing precedent, and they can make that rule from scratch. My concern is for the default build where there *is* an existing precedent that debian/rules build should work sanely, not for support for special cases like that where the existing debian/rules interface already doesn't do the right thing without additional help. If you are going to go down this path of having dpkg-buildpackage set up an environment that package maintainers should rely on, you or someone else on the dpkg team needs to make a debian-devel-announce post making it clear that debian/rules build is no longer a supported interface for building packages and using dpkg-buildpackage is required for consistent behavior. Right now, I don't think most Debian Developers have any idea what the implications of these changes are. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229357: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, 2008-09-11 at 10:53 -0700, Russ Allbery wrote: Raphael Hertzog [EMAIL PROTECTED] writes: On Wed, 10 Sep 2008, Bill Allombert wrote: I like to say I concurr with Russ. There are some much difference between packages that distributions wide default does not make sense. Such change would rather lead me to hardcode values of DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly. But more and more people want to be able to change distribution wide default: Emdebian wants to enable nodocs and nocheck by default, other want to be able to enable hardening options by default and I agree with them that official support for such a facility is desirable. So they should set DEB_BUILD_OPTIONS in the environment. That's what it's for. I don't have any objections to that, or even to doing it via dpkg-buildpackage. That is what DEB_VENDOR seeks to achieve - set it once and it sets the same options across all builds, in the environment. This is getting to be a long list of CC: - isn't it worth sending to debian-devel instead? Goswin von Brederlow and Simon Richter did a lot of work on this at Extremadura and they aren't on the current CC:. I'm losing track of all the bugs in the CC: and why they are listed. My objection is specifically to having dpkg-buildpackage set a variety of environment variables *by default*, and then telling package maintainers that they should rely on those environment variables being set in the default case. If by default you mean Debian, then NO. DEB_BUILD_OPTIONS is empty for Debian and will continue so. That breaks the debian/rules interface and requires that all package builds go through dpkg-buildpackage. Having dpkg-buildpackage set environment variables in the non-default case like Emdebian is not a problem, since for Emdebian builds (for example) Emdebian can decide that using dpkg-buildpackage or setting the environment variables manually is required. There is no existing precedent, and they can make that rule from scratch. Exactly. My concern is for the default build where there *is* an existing precedent that debian/rules build should work sanely, not for support for special cases like that where the existing debian/rules interface already doesn't do the right thing without additional help. If you are going to go down this path of having dpkg-buildpackage set up an environment that package maintainers should rely on, you or someone else on the dpkg team needs to make a debian-devel-announce post making it clear that debian/rules build is no longer a supported interface for building packages and using dpkg-buildpackage is required for consistent behavior. Right now, I don't think most Debian Developers have any idea what the implications of these changes are. That's fine. DEB_BUILD_OPTIONS would be empty if DEB_VENDOR is not set or is set to Debian. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
