Re: Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]
Hi! On Mon, 2009-02-09 at 09:30:48 +0100, Fabian Greffrath wrote: Introduction of the new fields == - Build-Recommends would list packages that are basically available in the Debian archive, but are not available on all architectures or for all kernels. [...] A famous example for this would be libasound2-dev, which is only available for Linux kernels. Currently a build-depends on this package has to look like this libasound2-dev [!hurd-i386 !kfreebsd-amd64 !kfreebsd-i386] to prevent apt from trying to install it on the non-Linux architectures where it is not available and thus would cause the build to fail. The new approach is as simple as moving libasound2-dev from Build-Depends to Build-Recommends. What you actually want here is to use architecture wildcards, as in: libasound2-dev [linux-any] this is documented in dpkg-architecture(1), and has been supported since dpkg 1.13.13. debhelper also supports this since 5.0.36. Currently the only missing piece I'm aware of is sbuild, but next upload to Debian should support it (#501230). It'd be really nice to get that patch on the buildds so that we could start using this in the archive. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]
Guillem Jover guil...@debian.org writes: What you actually want here is to use architecture wildcards, as in: libasound2-dev [linux-any] this is documented in dpkg-architecture(1), and has been supported since dpkg 1.13.13. debhelper also supports this since 5.0.36. Currently the only missing piece I'm aware of is sbuild, but next upload to Debian should support it (#501230). It'd be really nice to get that patch on the buildds so that we could start using this in the archive. If someone could provide a patch to Policy, that would be good too. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]
On Thu, 2009-02-12 at 20:37:06 -0800, Russ Allbery wrote: Guillem Jover guil...@debian.org writes: What you actually want here is to use architecture wildcards, as in: libasound2-dev [linux-any] this is documented in dpkg-architecture(1), and has been supported since dpkg 1.13.13. debhelper also supports this since 5.0.36. Currently the only missing piece I'm aware of is sbuild, but next upload to Debian should support it (#501230). It'd be really nice to get that patch on the buildds so that we could start using this in the archive. Hmm it seems pbuilder is lacking support as well (#363193). If someone could provide a patch to Policy, that would be good too. Yeah, I can do that in few days. Have been holding up until now as the they could not be used due to the buildd not supporting it. I guess it should not get applied into policy until we can actually use them on the archive, though. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]
Steve Langasek schrieb: This is a very bad idea. It interferes with reproducibility of binary builds, which is a very important property of Debian packages. Packages must *not* build differently based on opportunistic discovery of build-dependencies on the system - it's a bug for any package to do so, let alone to be specifically encouraging this behavior with debian/control fields! Alright, this speaks clearly against Build-Recommends. However, would you consider at least Build-Suggests useful enough to support them? Fabian -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]
On Tue, 10 Feb 2009 13:25:53 +0100 Fabian Greffrath greffr...@leat.rub.de wrote: Steve Langasek schrieb: This is a very bad idea. It interferes with reproducibility of binary builds, which is a very important property of Debian packages. Packages must *not* build differently based on opportunistic discovery of build-dependencies on the system - it's a bug for any package to do so, let alone to be specifically encouraging this behavior with debian/control fields! Alright, this speaks clearly against Build-Recommends. However, would you consider at least Build-Suggests useful enough to support them? AIUI, your original suggestion was that Build-Suggests was for use with external repositories, so it doesn't make any sense to have this data in debian/control where Policy requires that packages can only Build-Depend on packages that exist in Debian (i.e. must build from source in a sane way). If a package has extra functionality then Steve's point about *not discovering* such support is still valid - the program must default to OFF unless specifically configured to ON for the relevant switch. Builds must ignore any incidental packages that exist unless specifically requested to use them - which means changing debian/rules from --disable-foo to --enable-foo or similar. So IMHO the right place for information on what the package *can* do if suitably configured, is README.Debian - not debian/control - because merely installing the suggested package from whatever source must NOT allow the package to use this support within the build, the build itself (i.e. debian/rules) must be modified to look for this support. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpsmuLSn45ra.pgp Description: PGP signature
Re: Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]
Hi Fabian! Am Dienstag, den 10.02.2009, 13:25 +0100 schrieb Fabian Greffrath: Steve Langasek schrieb: This is a very bad idea. It interferes with reproducibility of binary builds, which is a very important property of Debian packages. Packages must *not* build differently based on opportunistic discovery of build-dependencies on the system - it's a bug for any package to do so, let alone to be specifically encouraging this behavior with debian/control fields! Alright, this speaks clearly against Build-Recommends. However, would you consider at least Build-Suggests useful enough to support them? If I got your proposal right, your use-case for Build-Suggests is that the package builds using additionally installed (development) packages, if they are already installed. A different method to achieve the same goal is to add a new option to DEB_BUILD_OPTIONS, in your case nonfree-codecs or something alike. You can check if it is set in debian/rules and change the build process accordingly to make use of the additional development packages. It has the drawback that you need to rely on the packages being installed already, so you may need to document it in README.Debian (or somewhere more appropriate) along with the option to pass in DEB_BUILD_OPTIONS but that's the same situation with your suggested Build-Suggests. (And as Neil pointed out, debian/rules should always behave in an off mode, meaning that the option only has an effect if it is set explicitely.) So all one needs to do to get the package with the non-free parts is to install the non-free -dev packages and do regular rebuild with DEB_BUILD_OPTIONS=nonfree-codes. That's easy enough, I think, and you do not need to modify the existing tools at all. Best regards Manuel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]
On Mon, 09 Feb 2009, Fabian Greffrath wrote: - Build-Recommends would list packages that are basically available in the Debian archive, but are not available on all architectures or for all kernels. Unfortunatly, making missing build-dependencies a non-fatal error causes builds to be non-deterministic. For example, consider a case where libasound2-dev was a no longer provided due to an API change to libasound3-dev, and for whatever reason, libasound3-dev wasn't installable on some arch subsets (perhaps because libasound3 hadn't yet been built.) Why have I added libfaad-dev to the Build-Recommends? Because in Ubuntu ffmpeg-debian is in the main section, while faad2 is not. So in order to merge ffmpeg-debian to Ubuntu, the maintainer has to manually remove this Build-Depends each and every time. As soon as Ubuntu would support the suggested approach, this would be obsolete. I wouldn't be averse to some method of describing additional types of conditional dependencies, such as differentiating builds of packages on Debian and Ubuntu. [A hideous method of doing this[1]: Build-Depends: libfaad-dev | some-only-in-ubuntu-package.] Don Armstrong 1: In fact, forget that I even mentioned this method; it's all kinds of ugly. -- Let us chat together a moment, my friend. There are still several hours until dawn, and I have the whole day to sleep. -- Count Orlock in _Nosferatu (1922)_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]
On Mon, Feb 09, 2009 at 09:30:48AM +0100, Fabian Greffrath wrote: Dear -devel, I'd like to suggest the introduction of two new control fields to the source stanza of debian/control, namely Build-Recommends and Build-Suggests. This is a very bad idea. It interferes with reproducibility of binary builds, which is a very important property of Debian packages. Packages must *not* build differently based on opportunistic discovery of build-dependencies on the system - it's a bug for any package to do so, let alone to be specifically encouraging this behavior with debian/control fields! A famous example for this would be libasound2-dev, which is only available for Linux kernels. Currently a build-depends on this package has to look like this libasound2-dev [!hurd-i386 !kfreebsd-amd64 !kfreebsd-i386] That is the correct relationship to express. Ensure libasound2-dev is used on all architectures except for these others is *not* the same thing as install libasound2-dev if you can find it. Why have I added libfaad-dev to the Build-Recommends? Because in Ubuntu ffmpeg-debian is in the main section, while faad2 is not. So in order to merge ffmpeg-debian to Ubuntu, the maintainer has to manually remove this Build-Depends each and every time. As soon as Ubuntu would support the suggested approach, this would be obsolete. That doesn't sound like a merge to me. A real merge, using tools such as Merge-o-Matic (http://merges.ubuntu.com) or a a VCS of choice, shouldn't require that any work be redone for this build-dependency difference. Trying to avoid deltas between Debian and Ubuntu by changing the semantics of build dependencies is a false optimization. It's not a win to save time on merges if it means unreliable build semantics in return. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]
On Mon, Feb 09, 2009 at 01:13:24AM -0800, Don Armstrong wrote: Why have I added libfaad-dev to the Build-Recommends? Because in Ubuntu ffmpeg-debian is in the main section, while faad2 is not. So in order to merge ffmpeg-debian to Ubuntu, the maintainer has to manually remove this Build-Depends each and every time. As soon as Ubuntu would support the suggested approach, this would be obsolete. I wouldn't be averse to some method of describing additional types of conditional dependencies, such as differentiating builds of packages on Debian and Ubuntu. [A hideous method of doing this[1]: Build-Depends: libfaad-dev | some-only-in-ubuntu-package.] I was going to suggest 'libfaad-dev | ubuntu-minimal' :) 1: In fact, forget that I even mentioned this method; it's all kinds of ugly. Aww :( -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]
On 09/02/09 at 01:13 -0800, Don Armstrong wrote: On Mon, 09 Feb 2009, Fabian Greffrath wrote: - Build-Recommends would list packages that are basically available in the Debian archive, but are not available on all architectures or for all kernels. Unfortunatly, making missing build-dependencies a non-fatal error causes builds to be non-deterministic. For example, consider a case where libasound2-dev was a no longer provided due to an API change to libasound3-dev, and for whatever reason, libasound3-dev wasn't installable on some arch subsets (perhaps because libasound3 hadn't yet been built.) Why have I added libfaad-dev to the Build-Recommends? Because in Ubuntu ffmpeg-debian is in the main section, while faad2 is not. So in order to merge ffmpeg-debian to Ubuntu, the maintainer has to manually remove this Build-Depends each and every time. As soon as Ubuntu would support the suggested approach, this would be obsolete. I wouldn't be averse to some method of describing additional types of conditional dependencies, such as differentiating builds of packages on Debian and Ubuntu. [A hideous method of doing this[1]: Build-Depends: libfaad-dev | some-only-in-ubuntu-package.] Couldn't we introduce a pseudo-arch/port named ubuntu, and use: Build-Depends: libfaad-dev [!ubuntu]? Of course, that leaves the question of whether Debian maintainers will agree to add Ubuntu-specific information in their source stanzas. But this doesn't have to be mandatory anyway. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]
Le Mon, Feb 09, 2009 at 09:30:48AM +0100, Fabian Greffrath a écrit : Dear -devel, I'd like to suggest the introduction of two new control fields to the source stanza of debian/control, namely Build-Recommends and Build-Suggests. Dear Fabian, this is a very intersting proposal that would address perfectly the issues I had with running regression tests with Perl modules. Let's imagine possible consequences (in the case of Perl modules) of unavailability of a package in one of the three Build- fields: - Binary packages would be impossible to prepare if Build-Depends are not completely satisfied. - Regression tests would miss some information if Build-Recommends are missing, but building would not fail and the binary package would be identical, i.e., the only diffrerence would be the logs. Advantage: a package does not become instantaneously unbuildable if one of its Build-Recommends is unavailable for whatever reason. - Regression tests would get additional information if Build-Suggests are present. Typically, Build-Suggests could be used with contrib or non-free packages. Here is a real life example: the bioperl-run package provides wrappers for many programs and regression tests for all the wrappers; most programs are packaged, and would go to to Build-Recommends, but some (clustalw, phylip) are non-free, and would go in Build-Suggests. Bioperl-run's regression tests do not fail if the wrapped programs are not found. This said, there are insightful comments in this thread that underline what should not be done with Build-Recommends in the context of packages that need compilation, so the need for the two new fields, althoug appalling, is probably not pressing. I guess that if you manage to convince the dpkg and sbuild maintainers to implement them, you will have more chances to get the fields accepted ;) Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
