Proposal of two new control fields: Build-Recommends and Build-Suggests [long reading]
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.
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. If a package listed in this field is available, it will
get installed by "apt-get build-dep" as if it was in Build-Depends --
but if it is not available, the build will not fail. This means that
only packages that add *optional functionality* and are *not required*
for the build may be considered as Build-Recommends.
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.
- Build-Suggests would list packages that add extra functionality to
the source package, but are not considered to get installed at
build-time by default. This will most probably cover unofficial
packages from external repositories, e.g. libmp3lame-dev or libfaac-dev.
Example
=======
A use case for this approach is given by the ffmpeg-debian package.
Currently its Build-Depends read like this (adjusted indentation for
better legibility):
Build-Depends: debhelper (>= 5.0.0),
libasound2-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386],
libdc1394-22-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386],
libfaad-dev | libfaad2-dev,
libfreetype6-dev,
libgsm1-dev,
libimlib2-dev,
libraw1394-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386],
libsdl1.2-dev,
libschroedinger-dev,
libspeex-dev,
libtheora-dev (>> 0.0.0.alpha4),
libvorbis-dev,
libx11-dev,
libxext-dev,
libxvmc-dev,
quilt,
texi2html,
zlib1g-dev
We find conditional Build-Depends on three packages: libasound2-dev,
libdc1394-22-dev and libraw1394-dev. With the suggested approach the
list of Build-Depends, Build-Recommends and Build-Suggests would read
like this:
Build-Depends: debhelper (>= 5.0.0),
libfreetype6-dev,
libgsm1-dev,
libimlib2-dev,
libsdl1.2-dev,
libschroedinger-dev,
libspeex-dev,
libtheora-dev (>> 0.0.0.alpha4),
libvorbis-dev,
libx11-dev,
libxext-dev,
libxvmc-dev,
quilt,
texi2html,
zlib1g-dev
Build-Recommends: libasound2-dev,
libdc1394-22-dev,
libfaad-dev | libfaad2-dev,
libraw1394-dev
Build-Suggests: libfaac-dev,
libmp3lame-dev,
libx264-dev,
libxvidcore-dev,
vdpau-dev
Please note that the Build-Depends that were architecture-conditional
before were moved to the Build-Recommends so they will
get installed like Build-Depends on archs where they are available
(i.e. all Linux archs) but will not cause the build to fail on other
archs.
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.
The Build-Suggests field lists packages that can be used by ffmpeg to
support additional codecs. They are not part of Debian for different
(mostly patent-related) reasons, so they should not even be considered
for installation at build-time. But if they are *already installed*,
they will result in additional features for the ffmpeg packages. So
the Build-Suggests field is more or less a hint for users who aim to
rebuild the package.
It should however not be a random list of "this could help" packages.
In ffmpeg for example we have introduced some header autodetection and
explicitely enable the additional codecs as soon as the corresponding
header file has been found on the system.
Further examples
================
Besides ffmpeg there are quite a lot packages in Debian which could
benefit from this approach. This includes generally all packages that
Build-Depend on the alsa or firewire headers. Furthermore all packages
that need their Build-Depends asjusted for includion in Ubuntu could
benefit from this.
There are already some packages which include support for additional
external libraries but need it manually activated, e.g. libquicktime
and gstreamer0.10-plugins-{bad,ugly}. These packages could list the
supported external libs in their Build-Suggests and thus give users a
hint which packages to install before recompilation in order to enable
additional codec support.
Comparison with binary package dependencies
===========================================
My proposal is very similar to the supported and well-established
relationships between binary packages [parts relevant to the new
approach are in squared brackets]:
- Everything in [Build-]Depends is really needed to get the [source]
package [building] running.
- Everything in [Build-]Recommends adds further functionality but is
not considered crucial, i.e. if it is missing for some reason it will
not break the [build process] program. It should be installed by
default and must not point to packages that are not available in
Debian main.
- Everything in [Build-]Suggests is really optional and may even point
to packages outside Debian main, if they add considerable value.
Implementation
==============
Well, since I don't have a clue of Debian packaging infrastructure
(i.e. I am well familiar with the packaging process, but I've never
had a closer look at the sources for dpkg, apt, dak, etc.) I cannot
tell if it would be a hard job to implement Build-Recommends --
although I don't believe so. ;)
Regarding Build-Suggests, this should be easy, since there is actually
nothing to implement at all. It "only" needs to accepted by
developers, used in their packages (with the XS- prefix) and establish
enough to finally lose the XS- prefix at some date in the future.
For my share, I am going to add XS-Source-Suggests headers to the
ffmpeg-debian and libquicktime package in the next revisions, so
everyone who is interested may inspect them and see "how it looks". ;)
So -devel, what do you think about this approach?
Cheers,
Fabian
PS: Please keep me in CC: as I am not subscribed to -devel. Thanks!
--
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: greffrath@leat.ruhr-uni-bochum.de
Reply to: