Package: debian-policy Version: 4.5.1.0 Severity: normal X-Debbugs-Cc: ftpmas...@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