Bug#774129: should dpkg-buildpackage set the cross build profile automatically?
Package: dpkg-dev Version: 1.17.23 Severity: wishlist User: helm...@debian.org Usertags: rebootstrap Some packages need extra Build-Depends when they are cross compiled. Here are some examples: * src:guile-2.0 needs guile-2.0 to cross-build * src:glib2.0 needs libglib2.0-dev:any to cross-build * src:autogen needs autogen to cross-build * src:flex runs help2man and an easy way to do that is to use the build arch flex * src:bison also runs help2man and can benefit from build arch bison A way to address this need is to use the cross build profile[1]. Now I am wondering whether dpkg-buildpackage should set the cross build profile automatically. The logic for doing so is as simple as: if the host architecture differs from the build architecture, enable that profile. Johannes Schauer pointed out that since there currently is no way to disable automatically enabled profiles, this can hamper debugging. A side effect of this change is that cross built packages would be reliably recognizable by looking at their Built-For-Profiles header. Arguably, adding a new header to record the build architecture would be a better facility. Also apt (and every other tool that installs Build-Depends) would need to set this profile automatically. If dpkg is not the place to add this facility, the place that invokes dpkg-buildpackage needs to enable this profile explicitly. That probably means that sbuild needs to do this. Thoughts? Helmut [1] https://wiki.debian.org/BuildProfileSpec -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774129: should dpkg-buildpackage set the cross build profile automatically?
+++ Helmut Grohne [2014-12-29 10:00 +0100]: Package: dpkg-dev Version: 1.17.23 Severity: wishlist User: helm...@debian.org Usertags: rebootstrap Some packages need extra Build-Depends when they are cross compiled. Here are some examples: * src:guile-2.0 needs guile-2.0 to cross-build * src:glib2.0 needs libglib2.0-dev:any to cross-build * src:autogen needs autogen to cross-build * src:flex runs help2man and an easy way to do that is to use the build arch flex * src:bison also runs help2man and can benefit from build arch bison A way to address this need is to use the cross build profile[1]. Now I am wondering whether dpkg-buildpackage should set the cross build profile automatically. The logic for doing so is as simple as: if the host architecture differs from the build architecture, enable that profile. If dpkg is not the place to add this facility, the place that invokes dpkg-buildpackage needs to enable this profile explicitly. That probably means that sbuild needs to do this. Thoughts? The thinking to date has been that this is not a job for the low-level tool dpkg-buildpackage. That provides the mechanism to set it but the environment sets things up. So yes, sbuild probably should do this, and pbuilder, and possibly debuild could/should do this, but I'm leery of dpkg-buildpackage doing it. But I could be wrong, and as we integrate this stuff more tightly, maybe it makes sense to move such functionality into lower-level tools. I have a feeling that dpkg-buildpackage should do 'policy' level build things so if the above became policy then dpkg-buildpackage should probably make sure it gets done. Perhaps the biggest disadvantage is indeed that if even the low-level build tool does this automatically then how do you turn it off? Is there is fact no good reason to ever want to? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774129: should dpkg-buildpackage set the cross build profile automatically?
Hi, Quoting Wookey (2014-12-29 13:14:20) I have a feeling that dpkg-buildpackage should do 'policy' level build things so if the above became policy then dpkg-buildpackage should probably make sure it gets done. Perhaps the biggest disadvantage is indeed that if even the low-level build tool does this automatically then how do you turn it off? Is there is fact no good reason to ever want to? on the topic of who should automatically set a certain build profile and how to deactivate it (if desired for whatever reason), my message to d-devel might be of interest: http://lists.debian.org/20141212114840.15300.27739@hoothoot It explores the idea of allowing an architecture or distribution dependent set of profiles which are activated by default to remove the architecture lists currently attached to many dependencies as well as to minimize the diff between packaging of different vendors. I don't want to conflate these two discussions, but maybe it is worth keeping this possible future use case of build profiles in mind when discussing who should activate the cross profile in particular and how it could be deactivated if desired. So just my 2 cents. cheers, josch -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719845: Will be easier to fix after patching findutils
I've just submitted a patch to GNU findutils that adds a -sort option doing the obvious thing. As noted in the earlier comments, this would be preferable to piping to sort. It's also a much smaller change than adding that into the pipeline. Hopefully, that will have reached upstream and been packaged before this issue gets revisited.
