Re: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Sep 18, 2008 at 03:03:20PM +0200, Goswin von Brederlow wrote: Russ Allbery [EMAIL PROTECTED] writes: 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. Setting the environment on a distribution wide level is ugly and fragile. Too many users will reset the environment in their .bashrc. Instead the idea was to have a vendor (set in /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults. The bugreports relevant for this have 2 solutions: 1) make dpkg-buildpackage use (or tool with equivalent environment setting up capabilities) mandatory 2) have debian/rules call something to set DEB_VENDOR and possibly more E.g. 'include /usr/share/dpkg/Makefile.dpkg' or 'DEB_VENDOR?= (shell dpkg-vendor -qDEB_VENDOR) DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS) The argument against 2 is that is requires every source to be modified if they want to support vendors whereas 1 only needs some small modification to dpkg-buildpackage to support calling arbitrary targets in debian/rules and a change in policy making its use mandatory. 2) is the right way to proceed for _Debian_. People in a hurry can use 1, but not us. 2) imply that packages will not have DEB_VENDOR support unless some check they support it. Right now, I don't think most Debian Developers have any idea what the implications of these changes are. I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. Precisely, debuild does not use dpkg-buildpackage, but call debian/rules directly. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Sep 18 2008, Goswin von Brederlow wrote: Russ Allbery [EMAIL PROTECTED] writes: Setting the environment on a distribution wide level is ugly and fragile. Too many users will reset the environment in their .bashrc. Instead the idea was to have a vendor (set in /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults. The bugreports relevant for this have 2 solutions: 1) make dpkg-buildpackage use (or tool with equivalent environment setting up capabilities) mandatory 2) have debian/rules call something to set DEB_VENDOR and possibly more E.g. 'include /usr/share/dpkg/Makefile.dpkg' or 'DEB_VENDOR?= (shell dpkg-vendor -qDEB_VENDOR) DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS) The argument against 2 is that is requires every source to be modified if they want to support vendors whereas 1 only needs some small modification to dpkg-buildpackage to support calling arbitrary targets in debian/rules and a change in policy making its use mandatory. But you need to modify the rules file anyway to take advantage of the DEB_VENDOR variable, no? Currently, setting it does nothing for any package. So if people are changing the rules file, they can also add in those two lines. 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. I tend to agree. Then you have one interface for Debian and one interface for every other vendor including ubuntu (or option 2 above). 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. I see that as a serious degradation in the quality of the distribution. Plus a note in policy clarifying that debian/rules is only an interface for dpkg-buildpackage but not users. No. Debian is a member of the free software community, and being able to just do a configure, or a build, or build a single binary, by end users, is a feature that should not be given up easily. And certainly not without some significant rationale; degrating features for most of our users to cater to other distributions does not actually cut it. Right now, I don't think most Debian Developers have any idea what the implications of these changes are. I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. I have never ever used debuild. So there is another anecdote, which may or may not mean anything. manoj -- Nothing can stop him. Not even common sense. Mark Komarinski Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, 18 Sep 2008, Bill Allombert wrote: I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. Precisely, debuild does not use dpkg-buildpackage, but call debian/rules directly. This has been fixed already. It calls dpkg-buildpackage now (except if you use its hook features). (And I don't see why one way would be more Debianish than the other) 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]
Re: Bug#489771: New Build-Options field and build-arch option, please review
Goswin von Brederlow [EMAIL PROTECTED] writes: Plus a note in policy clarifying that debian/rules is only an interface for dpkg-buildpackage but not users. Right. If you want to make this a rule, then we should discuss it, reach a consensus, document and publicize the change, and so forth. Right now, I feel like this change is being made as part of dpkg development, without general recognition of what's happening and without the corresponding changes to Policy so that DDs know what to expect. (I don't think this is *intentional* on your part, more a case of a set of decisions that all seemed like a good idea at the time but which cumulatively have a significant impact.) I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. The hard part of standards isn't the common case. Currently, debian/rules is defined as the package build interface, and while most people don't normally rely on that, we don't know what might break; one of the points of a standard is to let people rely on it without having to tell you first what they're doing. Personally, I use debian/rules build all the time for testing, and would never have thought to mention it to anyone. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Sep 18, 2008 at 05:36:46PM +0200, Raphael Hertzog wrote: On Thu, 18 Sep 2008, Bill Allombert wrote: I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. Precisely, debuild does not use dpkg-buildpackage, but call debian/rules directly. This has been fixed already. It calls dpkg-buildpackage now (except if you use its hook features). So it still call debian/rules directly in some case. (And I don't see why one way would be more Debianish than the other) Neither I do, but then I do not attempt to kill one way in favour of the other. I would object to a proposal policy making dpkg-buildpackage mandatory to build packages. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- 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
Russ Allbery [EMAIL PROTECTED] writes: 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. Setting the environment on a distribution wide level is ugly and fragile. Too many users will reset the environment in their .bashrc. Instead the idea was to have a vendor (set in /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults. The bugreports relevant for this have 2 solutions: 1) make dpkg-buildpackage use (or tool with equivalent environment setting up capabilities) mandatory 2) have debian/rules call something to set DEB_VENDOR and possibly more E.g. 'include /usr/share/dpkg/Makefile.dpkg' or 'DEB_VENDOR?= (shell dpkg-vendor -qDEB_VENDOR) DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS) The argument against 2 is that is requires every source to be modified if they want to support vendors whereas 1 only needs some small modification to dpkg-buildpackage to support calling arbitrary targets in debian/rules and a change in policy making its use mandatory. 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. Then you have one interface for Debian and one interface for every other vendor including ubuntu (or option 2 above). 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. Plus a note in policy clarifying that debian/rules is only an interface for dpkg-buildpackage but not users. Right now, I don't think most Debian Developers have any idea what the implications of these changes are. I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. MfG Goswin PS: with dpkg-buildpackage setting env vars like it does now you already have a verry confusing situation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489771: New Build-Options field and build-arch option, please review
On Thu, Sep 18, 2008 at 03:03:20PM +0200, Goswin von Brederlow wrote: Russ Allbery [EMAIL PROTECTED] writes: 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. Setting the environment on a distribution wide level is ugly and fragile. Too many users will reset the environment in their .bashrc. Instead the idea was to have a vendor (set in /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults. The bugreports relevant for this have 2 solutions: 1) make dpkg-buildpackage use (or tool with equivalent environment setting up capabilities) mandatory 2) have debian/rules call something to set DEB_VENDOR and possibly more E.g. 'include /usr/share/dpkg/Makefile.dpkg' or 'DEB_VENDOR?= (shell dpkg-vendor -qDEB_VENDOR) DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS) The argument against 2 is that is requires every source to be modified if they want to support vendors whereas 1 only needs some small modification to dpkg-buildpackage to support calling arbitrary targets in debian/rules and a change in policy making its use mandatory. 2) is the right way to proceed for _Debian_. People in a hurry can use 1, but not us. 2) imply that packages will not have DEB_VENDOR support unless some check they support it. Right now, I don't think most Debian Developers have any idea what the implications of these changes are. I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. Precisely, debuild does not use dpkg-buildpackage, but call debian/rules directly. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489771: New Build-Options field and build-arch option, please review
On Thu, 18 Sep 2008, Bill Allombert wrote: I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. Precisely, debuild does not use dpkg-buildpackage, but call debian/rules directly. This has been fixed already. It calls dpkg-buildpackage now (except if you use its hook features). (And I don't see why one way would be more Debianish than the other) 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
Goswin von Brederlow [EMAIL PROTECTED] writes: Plus a note in policy clarifying that debian/rules is only an interface for dpkg-buildpackage but not users. Right. If you want to make this a rule, then we should discuss it, reach a consensus, document and publicize the change, and so forth. Right now, I feel like this change is being made as part of dpkg development, without general recognition of what's happening and without the corresponding changes to Policy so that DDs know what to expect. (I don't think this is *intentional* on your part, more a case of a set of decisions that all seemed like a good idea at the time but which cumulatively have a significant impact.) I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. The hard part of standards isn't the common case. Currently, debian/rules is defined as the package build interface, and while most people don't normally rely on that, we don't know what might break; one of the points of a standard is to let people rely on it without having to tell you first what they're doing. Personally, I use debian/rules build all the time for testing, and would never have thought to mention it to anyone. -- 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, Sep 18, 2008 at 05:36:46PM +0200, Raphael Hertzog wrote: On Thu, 18 Sep 2008, Bill Allombert wrote: I have to say i verry rarely do not use debuild. And 99% of the exceptions are calling debian/rules clean. Precisely, debuild does not use dpkg-buildpackage, but call debian/rules directly. This has been fixed already. It calls dpkg-buildpackage now (except if you use its hook features). So it still call debian/rules directly in some case. (And I don't see why one way would be more Debianish than the other) Neither I do, but then I do not attempt to kill one way in favour of the other. I would object to a proposal policy making dpkg-buildpackage mandatory to build packages. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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]
Re: 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
Re: 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]
Re: 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
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
Re: New Build-Options field and build-arch option, please review
On Mon, Jul 14, 2008 at 01:22:58PM -0700, Russ Allbery wrote: Raphael Hertzog [EMAIL PROTECTED] writes: I think we're already on that path for quite some time. If your package uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting them for you (with dpkg-architecture). I most certainly do not rely on dpkg-buildpackage setting anything. I call dpkg-architecture directly, which is also what's in our best practice documents. DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) I would consider packages that didn't do that and just assumed that those variables were already set to be buggy. The same is expected with default values of builder/linker flags now that dpkg-buildpackage provides reasonable defaults. Yeah, that bothered me too. I made a perhaps poor tactical decision to not fight about it since it seemed that it had a lot of momentum and I couldn't think of specific problems other than the one that we ran into. But this is going beyond setting some defaults that are already set in nearly all of our packages. So yes, I'm somehow building on this model where dpkg-buildpackage can simplify the work of packager by providing some distribution-wide reasonable defaults. 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. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Build-Options field and build-arch option, please review
On Sun, 13 Jul 2008, Russ Allbery wrote: 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. I think we're already on that path for quite some time. If your package uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting them for you (with dpkg-architecture). The same is expected with default values of builder/linker flags now that dpkg-buildpackage provides reasonable defaults. So yes, I'm somehow building on this model where dpkg-buildpackage can simplify the work of packager by providing some distribution-wide reasonable defaults. 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). 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. Ok makes sense. In the case of hardening, it means that we have to modify each and every package to enable it though. I suppose that the people pushing this proposal would like to have the option to enable it globally and have broken packages opt out and/or disable specific hardening options. Without taking into account the specific risks associated to any default activation of build hardening, I find that having a generic system where you can start early with an opt-in policy, have the stuff matures, and switch to an opt-out policy later can make sense (if that plan is announced early and that people know by advance how to opt-out explicitely). 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. That might be so, but I'm not sure why it would be a major problem. It can take some time to change habits but unless you see real drawbacks, I'm not convinced that there are good reasons to revert in that direction. 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. Well, right now buildd do not use DEB_BUILD_OPTIONS at all AFAIK. So there's no way to enable anything globally with this method in practice. And I certainly wouldn't want to have to manually set DEB_BUILD_OPTIONS to get a build similar to what the buildd would do. The current practice only has options to disable something that is enabled by default. I'm not sure you can usefully build on that to provide a mechanism where something is disabled by default and that can be enabled either by the maintainer or by the builder. But maybe such a scheme is not desirable in general, we might not want to offer any option for the builder that has not been validated by the maintainer. I don't know. Maybe we won't have any other situation similar to the hardening one and it's over-kill to try to generalize it. the 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]
Re: New Build-Options field and build-arch option, please review
Raphael Hertzog [EMAIL PROTECTED] writes: I think we're already on that path for quite some time. If your package uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting them for you (with dpkg-architecture). I most certainly do not rely on dpkg-buildpackage setting anything. I call dpkg-architecture directly, which is also what's in our best practice documents. DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) I would consider packages that didn't do that and just assumed that those variables were already set to be buggy. The same is expected with default values of builder/linker flags now that dpkg-buildpackage provides reasonable defaults. Yeah, that bothered me too. I made a perhaps poor tactical decision to not fight about it since it seemed that it had a lot of momentum and I couldn't think of specific problems other than the one that we ran into. But this is going beyond setting some defaults that are already set in nearly all of our packages. So yes, I'm somehow building on this model where dpkg-buildpackage can simplify the work of packager by providing some distribution-wide reasonable defaults. 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.) Note that if you're requiring a package to participate by adding something to Build-Options in debian/control, you have the same transition problem, so I think that it's pretty equivalent to changing debian/rules; it's only when you want packages to be able to change with external defaults that you get the transition advantage. I don't want to underestimate the transition advantage -- that is pretty significant. I do understand the problem that you're trying to solve, and I understand that what I'm proposing is going to make transitions a lot harder. Ok makes sense. In the case of hardening, it means that we have to modify each and every package to enable it though. Well, not if you can do it via debhelper, which now with version 7 is much more likely. Similarly with cdbs. But in general, yes. For hardening, I think this is a feature; the flags aren't ones that can just be applied to every package without breaking things. I suppose that the people pushing this proposal would like to have the option to enable it globally and have broken packages opt out and/or disable specific hardening options. I think we've already found that this isn't a great approach for hardening options in particular, since they break too many packages (and those packages are not necessarily broken; in some cases it's the compiler that's broken, or the assumptions behind the options). Without taking into account the specific risks associated to any default activation of build hardening, I find that having a generic system where you can start early with an opt-in policy, have the stuff matures, and switch to an opt-out policy later can make sense (if that plan is announced early and that people know by advance how to opt-out explicitely). I agree with the benefit, but I think it's better to implement that sort of thing in the packaging tools that already do that sort of magic and which we already have a way of dealing with (compatibility levels in debhelper, for example), and which continue to work with debian/rules build. 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. That might be so, but I'm not sure why it would be a major problem. It can take some time to change habits but unless you see real drawbacks, I'm not convinced that there are good reasons to revert in that direction. I'm somewhat disturbed by this. Until this discussion, I had no idea that you were planning on deprecating debian/rules build and expecting everyone to use dpkg-buildpackage to get a reproducible build. I'm not even sure how to use dpkg-buildpackage to do the equivalent of just running debian/rules build without the binary-*
Bug#489771: New Build-Options field and build-arch option, please review
On Sun, 13 Jul 2008, Russ Allbery wrote: 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. I think we're already on that path for quite some time. If your package uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting them for you (with dpkg-architecture). The same is expected with default values of builder/linker flags now that dpkg-buildpackage provides reasonable defaults. So yes, I'm somehow building on this model where dpkg-buildpackage can simplify the work of packager by providing some distribution-wide reasonable defaults. 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). 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. Ok makes sense. In the case of hardening, it means that we have to modify each and every package to enable it though. I suppose that the people pushing this proposal would like to have the option to enable it globally and have broken packages opt out and/or disable specific hardening options. Without taking into account the specific risks associated to any default activation of build hardening, I find that having a generic system where you can start early with an opt-in policy, have the stuff matures, and switch to an opt-out policy later can make sense (if that plan is announced early and that people know by advance how to opt-out explicitely). 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. That might be so, but I'm not sure why it would be a major problem. It can take some time to change habits but unless you see real drawbacks, I'm not convinced that there are good reasons to revert in that direction. 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. Well, right now buildd do not use DEB_BUILD_OPTIONS at all AFAIK. So there's no way to enable anything globally with this method in practice. And I certainly wouldn't want to have to manually set DEB_BUILD_OPTIONS to get a build similar to what the buildd would do. The current practice only has options to disable something that is enabled by default. I'm not sure you can usefully build on that to provide a mechanism where something is disabled by default and that can be enabled either by the maintainer or by the builder. But maybe such a scheme is not desirable in general, we might not want to offer any option for the builder that has not been validated by the maintainer. I don't know. Maybe we won't have any other situation similar to the hardening one and it's over-kill to try to generalize it. the 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#489771: New Build-Options field and build-arch option, please review
Raphael Hertzog [EMAIL PROTECTED] writes: I think we're already on that path for quite some time. If your package uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting them for you (with dpkg-architecture). I most certainly do not rely on dpkg-buildpackage setting anything. I call dpkg-architecture directly, which is also what's in our best practice documents. DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) I would consider packages that didn't do that and just assumed that those variables were already set to be buggy. The same is expected with default values of builder/linker flags now that dpkg-buildpackage provides reasonable defaults. Yeah, that bothered me too. I made a perhaps poor tactical decision to not fight about it since it seemed that it had a lot of momentum and I couldn't think of specific problems other than the one that we ran into. But this is going beyond setting some defaults that are already set in nearly all of our packages. So yes, I'm somehow building on this model where dpkg-buildpackage can simplify the work of packager by providing some distribution-wide reasonable defaults. 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.) Note that if you're requiring a package to participate by adding something to Build-Options in debian/control, you have the same transition problem, so I think that it's pretty equivalent to changing debian/rules; it's only when you want packages to be able to change with external defaults that you get the transition advantage. I don't want to underestimate the transition advantage -- that is pretty significant. I do understand the problem that you're trying to solve, and I understand that what I'm proposing is going to make transitions a lot harder. Ok makes sense. In the case of hardening, it means that we have to modify each and every package to enable it though. Well, not if you can do it via debhelper, which now with version 7 is much more likely. Similarly with cdbs. But in general, yes. For hardening, I think this is a feature; the flags aren't ones that can just be applied to every package without breaking things. I suppose that the people pushing this proposal would like to have the option to enable it globally and have broken packages opt out and/or disable specific hardening options. I think we've already found that this isn't a great approach for hardening options in particular, since they break too many packages (and those packages are not necessarily broken; in some cases it's the compiler that's broken, or the assumptions behind the options). Without taking into account the specific risks associated to any default activation of build hardening, I find that having a generic system where you can start early with an opt-in policy, have the stuff matures, and switch to an opt-out policy later can make sense (if that plan is announced early and that people know by advance how to opt-out explicitely). I agree with the benefit, but I think it's better to implement that sort of thing in the packaging tools that already do that sort of magic and which we already have a way of dealing with (compatibility levels in debhelper, for example), and which continue to work with debian/rules build. 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. That might be so, but I'm not sure why it would be a major problem. It can take some time to change habits but unless you see real drawbacks, I'm not convinced that there are good reasons to revert in that direction. I'm somewhat disturbed by this. Until this discussion, I had no idea that you were planning on deprecating debian/rules build and expecting everyone to use dpkg-buildpackage to get a reproducible build. I'm not even sure how to use dpkg-buildpackage to do the equivalent of just running debian/rules build without the binary-*
Re: New Build-Options field and build-arch option, please review
Joey Hess [EMAIL PROTECTED] writes: Raphael Hertzog wrote: Even if there's only two things, the fact is that the package maintainer wants not only to decide what is supported but he might also want to enable some features... Did you think about having two fields, one to specify the set of supported options, and one to allow setting defaults? FWIW, Manoj, Steve, Yuri[1] and I had a good chat about this on the train across Scotland last summer. For some types of options, it makes sense to not just declare that they're supported, but that some particular combinations of options is supported, while declaring other combinations as unsupported. This would be particularly useful when setting compile options (including librarary link combinations). Similary the user might want to enable options that are supported, force enable (override) options that are undeclared or forbidden or disable options that are declared as default. It should be possible to specify a delta or mask to the packages options and not just set the options, e.g. to say use default options + bar - foo. Hmm, my notebook[2] from that trip suggests the following syntax: Build-Options: strip, debug, bar, foo, !foo+bar Indicating that foo and bar cannot be combined. Should that be more like Build-Options: strip, debug Build-Supported: bar, foo, !foo+bar, !baz Indicating that strip and debug should be used by default. Further bar and foo may be enable but not together and baz must not be used. Not that !baz would be different from not listing baz. !baz would be a strong indicator that the build will break. Also, I think it would be a good idea to explicitly make x-foo be reserved for non-standard options. Further I think it would be good if one could say use bar if supported in an environment variable or conffile. For example the user might want to use parallel building with 2 cores if the package supports it. But if the package does not then there should be no error. Otherwise one would have to change the environment for every build according to the package capabilities. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Build-Options field and build-arch option, please review
Hi, thanks for your answers. On Fri, 11 Jul 2008, Joey Hess wrote: Raphael Hertzog wrote: Even if there's only two things, the fact is that the package maintainer wants not only to decide what is supported but he might also want to enable some features... Did you think about having two fields, one to specify the set of supported options, and one to allow setting defaults? This might be possible but the limit is not always very clear: in the case of build-arch, the simple fact that it's supported means that it's enabled by default. It doesn't really make sense to require the maintainer to put it in Build-Options-Supported and also in Build-Options. For some types of options, it makes sense to not just declare that they're supported, but that some particular combinations of options is supported, while declaring other combinations as unsupported. This would be particularly useful when setting compile options (including librarary link combinations). You're thinking of options in terms of configure flags, is that right? --with-mysql might be incompatible with --with-postgresql but both might coexist with yet another feature. I'm not sure I want to go that far in the logic of Build-Options. I certainly would consider nice to have a sort of flavor mechanism where the maintainer can propose various combinations of options. Build-Options-Supported: flavor=mysql,postgresql,oracle,all Build-Options-Default: flavor=all But we could also express this with: Build-Options: possible-flavor=mysql,postgresql,oracle,all default-flavor=all (Well the set of prefix can be discussed and set in stone, exactly like I have used the no- prefix to disable an option previously set) Also, I think it would be a good idea to explicitly make x-foo be reserved for non-standard options. Fine. On Fri, 11 Jul 2008, Russ Allbery wrote: Raphael Hertzog [EMAIL PROTECTED] writes: Even if there's only two things, the fact is that the package maintainer wants not only to decide what is supported but he might also want to enable some features... if you check the case that I listed above, we also want to use Build-Options to _enable_ specific hardening measures. Because the maintainer knows best which hardening measures should be enabled. But we also want the builder to be able to override them for example to test if the package now supports a previously disabled hardening measure. 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? I'd rather see Build-Options in debian/control be clearly defined as capabilities that the package supports and not used as a substitute for the existing DEB_BUILD_OPTIONS method of controlling what the build does in practice. (And I'd prefer it to be called Build-Options-Supported or something along those lines.) I think this still fits for #489771; the presence of the hardening option in Build-Options-Supported indicates that the package can usefully be built with hardening (it doesn't cause the package build to break or the binaries to malfunction). Separating the two meanings is always possible, see above for a discussion. 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_) 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. 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). 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]
Re: New Build-Options field and build-arch option, please review
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]
Re: New Build-Options field and build-arch option, please review
Goswin von Brederlow [EMAIL PROTECTED] writes: Further I think it would be good if one could say use bar if supported in an environment variable or conffile. For example the user might want to use parallel building with 2 cores if the package supports it. But if the package does not then there should be no error. The existing DEB_BUILD_OPTIONS mechanism already supports exactly these semantics for the parallel=N option, so as long as we don't break what we already have working, this should continue to behave appropriately and we can add additional options for similar cases. -- 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#489771: New Build-Options field and build-arch option, please review
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]
Re: New Build-Options field and build-arch option, please review
On Thu, 10 Jul 2008, Felipe Sateler wrote: El 10/07/08 18:02 Raphael Hertzog escribió: Hello, in order to fix #229357 I decided to add a new Build-Options field. I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS. And I added support for a build-arch option, that if present, will let dpkg-buildpackage call debian/rules build-arch and build-indep. It's not obvious that this was the right choice when you think of the currently existing build options but once you start thinking of possible additions (as requested in #489771), it becomes more evident that it makes sense. Even if some build options should really only be used in the field while others should only be used in the environment variable, the possibility to override the former with the latter is nice. I'm not really sure this is right. There are two things that we want to do here: declare that a package supports something, and asking the package to do something. This difference is blurred now, and I think it is confusing. Even if there's only two things, the fact is that the package maintainer wants not only to decide what is supported but he might also want to enable some features... if you check the case that I listed above, we also want to use Build-Options to _enable_ specific hardening measures. Because the maintainer knows best which hardening measures should be enabled. But we also want the builder to be able to override them for example to test if the package now supports a previously disabled hardening measure. The meaning of each build options is specific to each, there's no global rule that works for all cases. That's why we have documentation of each option in dpkg-buildpackage. I fear it will give rise to abuses such as setting parallel=n in the control file. There are dozens of ways to abuse any interface if you choose to use it in a way that contradicts the documentation. But that's not a reason to limit the flexibility offered by an interface. 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]
Re: New Build-Options field and build-arch option, please review
On Thu, Jul 10, 2008 at 07:19:16PM -0400, Felipe Sateler wrote: El 10/07/08 18:02 Raphael Hertzog escribió: Hello, in order to fix #229357 I decided to add a new Build-Options field. I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS. And I added support for a build-arch option, that if present, will let dpkg-buildpackage call debian/rules build-arch and build-indep. It's not obvious that this was the right choice when you think of the Maybe it is not obvious, but since noone proposed another working solution in the ten years this issue exists, there is no alternative. currently existing build options but once you start thinking of possible additions (as requested in #489771), it becomes more evident that it makes sense. Even if some build options should really only be used in the field while others should only be used in the environment variable, the possibility to override the former with the latter is nice. I'm not really sure this is right. There are two things that we want to do here: declare that a package supports something, and asking the package to do something. This difference is blurred now, and I think it is confusing. OTOH, it gives the benefit of being able to ignore the package capabilities via the environment (ie, unset a given option). I fear it will give rise to abuses such as setting parallel=n in the control file. I concur. This also create a namespace problem by conflating the 'Build-Options' namespace with the DEB_BUILD_OPTIONS namespace. Since a developer can put virtually anything in DEB_BUILD_OPTIONS (and check for it in debian/rules) even if it is not mentionned in policy, this is a real issue. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Build-Options field and build-arch option, please review
Raphael Hertzog wrote: Even if there's only two things, the fact is that the package maintainer wants not only to decide what is supported but he might also want to enable some features... Did you think about having two fields, one to specify the set of supported options, and one to allow setting defaults? FWIW, Manoj, Steve, Yuri[1] and I had a good chat about this on the train across Scotland last summer. For some types of options, it makes sense to not just declare that they're supported, but that some particular combinations of options is supported, while declaring other combinations as unsupported. This would be particularly useful when setting compile options (including librarary link combinations). Hmm, my notebook[2] from that trip suggests the following syntax: Build-Options: strip, debug, bar, foo, !foo+bar Indicating that foo and bar cannot be combined. Also, I think it would be a good idea to explicitly make x-foo be reserved for non-standard options. -- see shy jo [1] A gentoo guy. Who better to discuss build options. ;-) [2] http://farm2.static.flickr.com/1121/639896787_dfe8d0f8c2.jpg signature.asc Description: Digital signature
Re: New Build-Options field and build-arch option, please review
Raphael Hertzog [EMAIL PROTECTED] writes: Even if there's only two things, the fact is that the package maintainer wants not only to decide what is supported but he might also want to enable some features... if you check the case that I listed above, we also want to use Build-Options to _enable_ specific hardening measures. Because the maintainer knows best which hardening measures should be enabled. But we also want the builder to be able to override them for example to test if the package now supports a previously disabled hardening measure. 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? I'd rather see Build-Options in debian/control be clearly defined as capabilities that the package supports and not used as a substitute for the existing DEB_BUILD_OPTIONS method of controlling what the build does in practice. (And I'd prefer it to be called Build-Options-Supported or something along those lines.) I think this still fits for #489771; the presence of the hardening option in Build-Options-Supported indicates that the package can usefully be built with hardening (it doesn't cause the package build to break or the binaries to malfunction). 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. They're going to have to test each flag that goes into the hardening options separately anyway to make sure that it works (the current proposed hardening flags break many packages, and if you follow debian/changelog files, you'll see that many maintainers have added them blindly and then had to roll back when they break). Using a debian/control field to set DEB_BUILD_OPTIONS in dpkg-buildpackage is a solution looking for a problem, IMO, and I'd rather not see that tangled up with the much-needed problem of specifying which options a package supports and finally dealing with the whole build-arch/build-indep mess. -- 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: New Build-Options field and build-arch option, please review
On Thu, 10 Jul 2008, Felipe Sateler wrote: El 10/07/08 18:02 Raphael Hertzog escribió: Hello, in order to fix #229357 I decided to add a new Build-Options field. I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS. And I added support for a build-arch option, that if present, will let dpkg-buildpackage call debian/rules build-arch and build-indep. It's not obvious that this was the right choice when you think of the currently existing build options but once you start thinking of possible additions (as requested in #489771), it becomes more evident that it makes sense. Even if some build options should really only be used in the field while others should only be used in the environment variable, the possibility to override the former with the latter is nice. I'm not really sure this is right. There are two things that we want to do here: declare that a package supports something, and asking the package to do something. This difference is blurred now, and I think it is confusing. Even if there's only two things, the fact is that the package maintainer wants not only to decide what is supported but he might also want to enable some features... if you check the case that I listed above, we also want to use Build-Options to _enable_ specific hardening measures. Because the maintainer knows best which hardening measures should be enabled. But we also want the builder to be able to override them for example to test if the package now supports a previously disabled hardening measure. The meaning of each build options is specific to each, there's no global rule that works for all cases. That's why we have documentation of each option in dpkg-buildpackage. I fear it will give rise to abuses such as setting parallel=n in the control file. There are dozens of ways to abuse any interface if you choose to use it in a way that contradicts the documentation. But that's not a reason to limit the flexibility offered by an interface. 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#489771: New Build-Options field and build-arch option, please review
On Thu, Jul 10, 2008 at 07:19:16PM -0400, Felipe Sateler wrote: El 10/07/08 18:02 Raphael Hertzog escribió: Hello, in order to fix #229357 I decided to add a new Build-Options field. I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS. And I added support for a build-arch option, that if present, will let dpkg-buildpackage call debian/rules build-arch and build-indep. It's not obvious that this was the right choice when you think of the Maybe it is not obvious, but since noone proposed another working solution in the ten years this issue exists, there is no alternative. currently existing build options but once you start thinking of possible additions (as requested in #489771), it becomes more evident that it makes sense. Even if some build options should really only be used in the field while others should only be used in the environment variable, the possibility to override the former with the latter is nice. I'm not really sure this is right. There are two things that we want to do here: declare that a package supports something, and asking the package to do something. This difference is blurred now, and I think it is confusing. OTOH, it gives the benefit of being able to ignore the package capabilities via the environment (ie, unset a given option). I fear it will give rise to abuses such as setting parallel=n in the control file. I concur. This also create a namespace problem by conflating the 'Build-Options' namespace with the DEB_BUILD_OPTIONS namespace. Since a developer can put virtually anything in DEB_BUILD_OPTIONS (and check for it in debian/rules) even if it is not mentionned in policy, this is a real issue. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489771: New Build-Options field and build-arch option, please review
Raphael Hertzog [EMAIL PROTECTED] writes: Even if there's only two things, the fact is that the package maintainer wants not only to decide what is supported but he might also want to enable some features... if you check the case that I listed above, we also want to use Build-Options to _enable_ specific hardening measures. Because the maintainer knows best which hardening measures should be enabled. But we also want the builder to be able to override them for example to test if the package now supports a previously disabled hardening measure. 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? I'd rather see Build-Options in debian/control be clearly defined as capabilities that the package supports and not used as a substitute for the existing DEB_BUILD_OPTIONS method of controlling what the build does in practice. (And I'd prefer it to be called Build-Options-Supported or something along those lines.) I think this still fits for #489771; the presence of the hardening option in Build-Options-Supported indicates that the package can usefully be built with hardening (it doesn't cause the package build to break or the binaries to malfunction). 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. They're going to have to test each flag that goes into the hardening options separately anyway to make sure that it works (the current proposed hardening flags break many packages, and if you follow debian/changelog files, you'll see that many maintainers have added them blindly and then had to roll back when they break). Using a debian/control field to set DEB_BUILD_OPTIONS in dpkg-buildpackage is a solution looking for a problem, IMO, and I'd rather not see that tangled up with the much-needed problem of specifying which options a package supports and finally dealing with the whole build-arch/build-indep mess. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New Build-Options field and build-arch option, please review
Hello,
in order to fix #229357 I decided to add a new Build-Options field.
I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
And I added support for a build-arch option, that if present, will let
dpkg-buildpackage call debian/rules build-arch and build-indep.
It's not obvious that this was the right choice when you think of the
currently existing build options but once you start thinking of possible
additions (as requested in #489771), it becomes more evident that it makes
sense. Even if some build options should really only be used in
the field while others should only be used in the environment variable,
the possibility to override the former with the latter is nice.
The current patchset is available in my public repository but I'll attach
it as well so that you can easily review it. I intend to merge it this
week-end after some tests but feel free to test and comment in the mean
time.
http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/bug229357-build-options
The patchset only applies on top of master.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
From 1ebeff797bc36c91e50f02c6d32cba094e827add Mon Sep 17 00:00:00 2001
From: Raphael Hertzog [EMAIL PROTECTED]
Date: Sun, 6 Jul 2008 22:03:27 +0200
Subject: [PATCH] Refactor Dpkg::BuildOptions to handle Build-Options field
* scripts/Dpkg/BuildOptions.pm: complete rewrite of the module
to handle various sources of build options: some options are auto-set
based on the standards version, then the maintainer can define options
with the Build-Options field in debian/control and last the builder
can use DEB_BUILD_OPTIONS to override everything. Some options are
meant to be exported through DEB_BUILD_OPTIONS and some are not.
* scripts/t/300_Dpkg_BuildOptions.t: adjust test suite for the new module
* scripts/dpkg-buildpackage.pl: adjust to use the new Dpkg::BuildOptions
API.
* scripts/Dpkg/Fields.pm, scripts/Dpkg/Source/Package.pm: add the new
Build-Options field as a valid field in the source section of
debian/control (and in .dsc files).
---
scripts/Dpkg/BuildOptions.pm | 257 +
scripts/Dpkg/Fields.pm|2 +-
scripts/Dpkg/Source/Package.pm|5 +-
scripts/dpkg-buildpackage.pl | 10 +-
scripts/t/300_Dpkg_BuildOptions.t | 61 +
5 files changed, 273 insertions(+), 62 deletions(-)
diff --git a/scripts/Dpkg/BuildOptions.pm b/scripts/Dpkg/BuildOptions.pm
index 9d6741b..5b2acdd 100644
--- a/scripts/Dpkg/BuildOptions.pm
+++ b/scripts/Dpkg/BuildOptions.pm
@@ -5,51 +5,252 @@ use warnings;
use Dpkg::Gettext;
use Dpkg::ErrorHandling qw(warning);
+use Dpkg::Control;
+use Dpkg::Version qw(compare_versions);
-sub parse {
-my ($env) = @_;
+# Define behavior for known options:
+# export - the option is meant to be exported in DEB_BUILD_OPTIONS
+# valued - the option can have a value
+# check_value_rx - if defined, a regex to check the value, invalid value
+# will lead to the option being discarded
+# min_standards_version - if the s-v field is = to the version given,
+# the option is auto-enabled
+our %OPTIONS = (
+noopt = {
+export = 1,
+valued = 0,
+},
+nostrip = {
+export = 1,
+valued = 0,
+},
+nocheck = {
+export = 1,
+valued = 0,
+},
+parallel = {
+export = 1,
+valued = 1,
+check_value_rx = qr/^-?\d+$/,
+},
+);
-$env ||= $ENV{DEB_BUILD_OPTIONS};
+=head1 NAME
-unless ($env) { return {}; }
+Dpkg::BuildOptions - handle build options from debian/control and environment
-my %opts;
+=head1 DESCRIPTION
-foreach (split(/\s+/, $env)) {
- unless (/^([a-z][a-z0-9_-]*)(=(\S*))?$/) {
-warning(_g(invalid flag in DEB_BUILD_OPTIONS: %s), $_);
-next;
+It provides an object to analyze and manipulate build options as defined
+by combining information provided by the debian/control file and by the
+DEB_BUILD_OPTIONS environment variable.
+
+=head1 FUNCTIONS
+
+=over 4
+
+=item $b = Dpkg::BuildOptions($file)
+
+Create a new Dpkg::BuildOptions object. The $file parameter is simply
+forwarded to Dpkg::Control-new($file). If undef, it will simply use
+debian/control by default.
+
+=cut
+sub new {
+my ($this, $ctl_file) = @_;
+my $class = ref($this) || $this;
+my $self = {
+'opts' = {},
+'control' = Dpkg::Control-new($ctl_file),
+};
+bless $self, $class;
+$self-parse_options();
+return $self;
+}
+
+=item $b-reset()
+
+Forget all options already parsed. Start afresh.
+
+=cut
+sub reset {
+my ($self) = @_;
+$self-{'opts'} = {};
+}
+
+=item $b-parse_options()
+
+Do a full parse of options, including the Build-Options field in
+debian/control and the DEB_BUILD_OPTIONS variable.
+
+=cut
+sub parse_options {
+my ($self) = @_;
+
Re: New Build-Options field and build-arch option, please review
El 10/07/08 18:02 Raphael Hertzog escribió: Hello, in order to fix #229357 I decided to add a new Build-Options field. I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS. And I added support for a build-arch option, that if present, will let dpkg-buildpackage call debian/rules build-arch and build-indep. It's not obvious that this was the right choice when you think of the currently existing build options but once you start thinking of possible additions (as requested in #489771), it becomes more evident that it makes sense. Even if some build options should really only be used in the field while others should only be used in the environment variable, the possibility to override the former with the latter is nice. I'm not really sure this is right. There are two things that we want to do here: declare that a package supports something, and asking the package to do something. This difference is blurred now, and I think it is confusing. OTOH, it gives the benefit of being able to ignore the package capabilities via the environment (ie, unset a given option). I fear it will give rise to abuses such as setting parallel=n in the control file. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Bug#229357: New Build-Options field and build-arch option, please review
Hello,
in order to fix #229357 I decided to add a new Build-Options field.
I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS.
And I added support for a build-arch option, that if present, will let
dpkg-buildpackage call debian/rules build-arch and build-indep.
It's not obvious that this was the right choice when you think of the
currently existing build options but once you start thinking of possible
additions (as requested in #489771), it becomes more evident that it makes
sense. Even if some build options should really only be used in
the field while others should only be used in the environment variable,
the possibility to override the former with the latter is nice.
The current patchset is available in my public repository but I'll attach
it as well so that you can easily review it. I intend to merge it this
week-end after some tests but feel free to test and comment in the mean
time.
http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/bug229357-build-options
The patchset only applies on top of master.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
From 1ebeff797bc36c91e50f02c6d32cba094e827add Mon Sep 17 00:00:00 2001
From: Raphael Hertzog [EMAIL PROTECTED]
Date: Sun, 6 Jul 2008 22:03:27 +0200
Subject: [PATCH] Refactor Dpkg::BuildOptions to handle Build-Options field
* scripts/Dpkg/BuildOptions.pm: complete rewrite of the module
to handle various sources of build options: some options are auto-set
based on the standards version, then the maintainer can define options
with the Build-Options field in debian/control and last the builder
can use DEB_BUILD_OPTIONS to override everything. Some options are
meant to be exported through DEB_BUILD_OPTIONS and some are not.
* scripts/t/300_Dpkg_BuildOptions.t: adjust test suite for the new module
* scripts/dpkg-buildpackage.pl: adjust to use the new Dpkg::BuildOptions
API.
* scripts/Dpkg/Fields.pm, scripts/Dpkg/Source/Package.pm: add the new
Build-Options field as a valid field in the source section of
debian/control (and in .dsc files).
---
scripts/Dpkg/BuildOptions.pm | 257 +
scripts/Dpkg/Fields.pm|2 +-
scripts/Dpkg/Source/Package.pm|5 +-
scripts/dpkg-buildpackage.pl | 10 +-
scripts/t/300_Dpkg_BuildOptions.t | 61 +
5 files changed, 273 insertions(+), 62 deletions(-)
diff --git a/scripts/Dpkg/BuildOptions.pm b/scripts/Dpkg/BuildOptions.pm
index 9d6741b..5b2acdd 100644
--- a/scripts/Dpkg/BuildOptions.pm
+++ b/scripts/Dpkg/BuildOptions.pm
@@ -5,51 +5,252 @@ use warnings;
use Dpkg::Gettext;
use Dpkg::ErrorHandling qw(warning);
+use Dpkg::Control;
+use Dpkg::Version qw(compare_versions);
-sub parse {
-my ($env) = @_;
+# Define behavior for known options:
+# export - the option is meant to be exported in DEB_BUILD_OPTIONS
+# valued - the option can have a value
+# check_value_rx - if defined, a regex to check the value, invalid value
+# will lead to the option being discarded
+# min_standards_version - if the s-v field is = to the version given,
+# the option is auto-enabled
+our %OPTIONS = (
+noopt = {
+export = 1,
+valued = 0,
+},
+nostrip = {
+export = 1,
+valued = 0,
+},
+nocheck = {
+export = 1,
+valued = 0,
+},
+parallel = {
+export = 1,
+valued = 1,
+check_value_rx = qr/^-?\d+$/,
+},
+);
-$env ||= $ENV{DEB_BUILD_OPTIONS};
+=head1 NAME
-unless ($env) { return {}; }
+Dpkg::BuildOptions - handle build options from debian/control and environment
-my %opts;
+=head1 DESCRIPTION
-foreach (split(/\s+/, $env)) {
- unless (/^([a-z][a-z0-9_-]*)(=(\S*))?$/) {
-warning(_g(invalid flag in DEB_BUILD_OPTIONS: %s), $_);
-next;
+It provides an object to analyze and manipulate build options as defined
+by combining information provided by the debian/control file and by the
+DEB_BUILD_OPTIONS environment variable.
+
+=head1 FUNCTIONS
+
+=over 4
+
+=item $b = Dpkg::BuildOptions($file)
+
+Create a new Dpkg::BuildOptions object. The $file parameter is simply
+forwarded to Dpkg::Control-new($file). If undef, it will simply use
+debian/control by default.
+
+=cut
+sub new {
+my ($this, $ctl_file) = @_;
+my $class = ref($this) || $this;
+my $self = {
+'opts' = {},
+'control' = Dpkg::Control-new($ctl_file),
+};
+bless $self, $class;
+$self-parse_options();
+return $self;
+}
+
+=item $b-reset()
+
+Forget all options already parsed. Start afresh.
+
+=cut
+sub reset {
+my ($self) = @_;
+$self-{'opts'} = {};
+}
+
+=item $b-parse_options()
+
+Do a full parse of options, including the Build-Options field in
+debian/control and the DEB_BUILD_OPTIONS variable.
+
+=cut
+sub parse_options {
+my ($self) = @_;
+
Bug#229357: New Build-Options field and build-arch option, please review
El 10/07/08 18:02 Raphael Hertzog escribió: Hello, in order to fix #229357 I decided to add a new Build-Options field. I modified Dpkg::BuildOptions to parse this field and DEB_BUILD_OPTIONS. And I added support for a build-arch option, that if present, will let dpkg-buildpackage call debian/rules build-arch and build-indep. It's not obvious that this was the right choice when you think of the currently existing build options but once you start thinking of possible additions (as requested in #489771), it becomes more evident that it makes sense. Even if some build options should really only be used in the field while others should only be used in the environment variable, the possibility to override the former with the latter is nice. I'm not really sure this is right. There are two things that we want to do here: declare that a package supports something, and asking the package to do something. This difference is blurred now, and I think it is confusing. OTOH, it gives the benefit of being able to ignore the package capabilities via the environment (ie, unset a given option). I fear it will give rise to abuses such as setting parallel=n in the control file. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
