Bug#984511: debian-policy: please clarify how archive areas can be combined in source packages
Package: debian-policy
Version: 4.5.1.0
Severity: normal
X-Debbugs-Cc: ftpmaster@debian.org
Package maintainers (including me, most of the time) tend to assume that
each source package has to exist in exactly one archive area, and all
of its binary packages have to go into that same archive area. However,
Ansgar tells me this is not actually true.
Some of the terms in use here are overloaded, so please be careful. At the
dpkg level, there is a Section field in d/control and in binary package
metadata. Despite its name, this field actually combines the user-facing
section (admin, games, libdevel and so on) and the archive area (main,
contrib or non-free). In this mail I will use Section (titlecase) for the
field, and section (lower-case) for the user-facing section.
.dsc files do not include a Section field, but both source and binary
packages have to exist in an archive area, so when accepting uploaded
packages the archive software has to guess which archive area the
source package ought to be in, based on the Section of the various
binary packages in its Package-List field.
The Section in the first stanza of d/control is a default for all binary
packages that do not explicitly specify their Section, but is not copied
into the .dsc file - although perhaps it should be?
My understanding is that the ftp team allows the following situations:
* A source package builds binary packages that are all in main
(e.g. dpkg). The source package is Free and gets put in main.
Example d/control (simplified down to just the relevant parts):
Source: dpkg
# this implicitly means archive area: main, section: admin
Section: admin
Package: dpkg
Package: dpkg-dev
# this implicitly means archive area: main, section: utils
Section: utils
* A source package builds binary packages that are all in contrib
(e.g. src:game-data-packager). The source package is Free, and gets put
in contrib too.
Example d/control (simplified down to just the relevant parts):
Source: game-data-packager
# this means archive area: contrib, section: games
Section: contrib/games
Package: game-data-packager
Package: quake
* A source package builds binary packages that are all in non-free
(e.g. src:steam). The source package is at least partially non-Free
and gets put in non-free.
Example d/control (simplified down to just the relevant parts):
Source: steam
# this means archive area: non-free, section: games
Section: non-free/games
Package: steam
Package: steam-devices
* A source package builds a mixture of binary packages that are
suitable for main and binary packages suitable for contrib
(e.g. src:cpl-plugin-amber, where cpl-plugin-amber-calib is contrib
and the rest is in main). The source package is Free, even though
some of its binary packages have external and/or non-free dependencies,
so it can be put in main.
Example d/control (simplified down to just the relevant parts):
Source: cpl-plugin-amber
# this implicitly means archive area: main, section: science
Section: science
Package: cpl-plugin-amber
Package: cpl-plugin-amber-calib
# this means archive area: contrib, section: science
Section: contrib/science
In particular, a source package is not allowed to combine non-free binary
packages with main or contrib binary packages: the important parts of
steam-devices.deb are actually Free (MIT-licensed), but if I wanted to put
those in main, I would have to split the source package into an entirely
Free part to build steam-devices.deb, and a non-Free part to build steam.deb.
>From the Policy text, it is not clear that the last one of those four
situations (as used in cpl-plugin-amber) is allowed. It would be useful for
Policy to explicitly say that it is, so that it's available as a tool for
maintainers to use when appropriate.
Questions for the ftp team:
* Is my understanding of this correct?
* Are source packages like cpl-plugin-amber, that mix main and contrib
binary packages, considered to be something that is entirely valid and
should be used whenever it is the closest representation of reality;
or is this considered to be deprecated feature that should be avoided,
with maintainers preferring to split the source package into a part
that builds 100% main binary packages and a part that builds 100%
contrib binary packages?
One concrete place where this could be useful is that src:pipewire
optionally builds a plugin that uses fdk-aac (in non-free) for better
Bluetooth support. This is currently disabled via a Build-Conflicts in
Debian, but users of some Bluetooth headsets would prefer to be able to
use it. If pipewire could build everything from a single source package in
main, and produce binary packages that are mostly main but also include
a contrib plugin for fdk-aac, then that would be a lot easier than a
separate pipewire-contrib source package.
smcv
Reply to: