Package: debian-policy
Version: 4.6.0.1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: ftpmas...@debian.org

If you have an upstream project consisting of Free source code with a
mixture of Free and non-Free dependencies, it isn't currently clear how
that should be packaged.

For example, if gnome-software added a steam plugin that was itself Free
Software, but had Depends: steam, then it would be in this situation:
the program and the flatpak and snap plugins would still be suitable
for main, but the steam plugin would need to go in contrib.

Based on the precedent seen in the bumblebee package, I believe the
ftp team's intention is that packages like this are allowed to be a
single source package in main, which builds binary packages for main
and contrib, even though this means the contrib binary packages don't
match their source package's archive area.

I think I remember talking to a ftp team member about this in person
and coming to the conclusion that there are good reasons for none of
the other possible source/binary archive area mismatches to be allowed.

In the form of a table, the allowed source/binary combinations are:

                      |        binary           |
                      | main  contrib  non-free |
     -----------------|-------------------------|
             main     |  yes    yes      -      |
     source  contrib  |   -     yes      -      |
             non-free |   -      -      yes     |

ftp team: is this correct?

If it is, I attach proposed patches for Policy. Their commit messages
attempt to capture the rationale for why the other situations are not
allowed; corrections/clarifications welcome.

Thanks,
    smcv
>From eda0f325301bd514e5ac94328dd4b5a01960634a Mon Sep 17 00:00:00 2001
From: Simon McVittie <s...@debian.org>
Date: Thu, 9 Sep 2021 15:43:20 +0100
Subject: [PATCH 1/2] archive: Point out that mixed main/contrib source
 packages can exist

Most source packages produce only binary packages in the same archive
area, but a few source packages in main (such as bumblebee) produce
a mixture of main and contrib binary packages.

If an upstream project is in this situation (for example a program with
optional plugins that have non-free dependencies) it isn't entirely
obvious how to package it; clarify that a single source package in main
is considered to be appropriate in this case, as long as no non-free
build-dependencies are required.

Signed-off-by: Simon McVittie <s...@debian.org>
---
 policy/ch-archive.rst | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index ab04261..7829601 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -130,6 +130,19 @@ In addition, the packages in *main*
 
 - must meet all policy requirements presented in this manual.
 
+If a source package is in the *main* archive area, then each of the
+binary packages that it produces must be in either the *main* or *contrib*
+archive area. Each binary package's archive area is indicated by its
+``Section`` field: see :ref:`s-subsections`.
+
+When a *main* source package has a mixture of *main* and *contrib*
+binary packages, the source package and the *main* binary packages must
+follow the requirements for *main* packages, but the *contrib* binary
+packages may follow the weaker requirements for *contrib* packages.
+In particular, build-dependencies outside *main* are not allowed in
+these source packages, but the *contrib* binary packages may have runtime
+dependencies outside *main*.
+
 .. _s-contrib:
 
 The contrib archive area
-- 
2.33.0

>From 0b855a4a0dbb348269388985fc45c7887376a245 Mon Sep 17 00:00:00 2001
From: Simon McVittie <s...@debian.org>
Date: Thu, 9 Sep 2021 15:53:20 +0100
Subject: [PATCH 2/2] archive: Clarify binaries produced by contrib and
 non-free source

A source package outside main cannot produce main binary packages, because
we want main to be self-contained: if you download all main source
packages, that should give you the source code of all main binary
packages.

A source package in contrib cannot produce non-free binary packages,
because by definition contrib only contains free software (with non-free
dependencies, but those are not part of the source code).

A source package in non-free cannot produce contrib binary packages,
because we want main + contrib to be self-contained: if you download
all main or contrib source packages, that should give you the source
code of all main and contrib binary packages.

Signed-off-by: Simon McVittie <s...@debian.org>
---
 policy/ch-archive.rst | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index 7829601..35b44bb 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -169,6 +169,10 @@ Examples of packages which would be included in *contrib* are:
 -  wrapper packages or other sorts of free accessories for non-free
    programs.
 
+If a source package is in the *contrib* archive area, then each of the
+binary packages that it produces must also be in the *contrib* archive
+area.
+
 .. _s-non-free:
 
 The non-free archive area
@@ -191,6 +195,10 @@ In addition, the packages in *non-free*
 -  must meet all policy requirements presented in this manual that it is
    possible for them to meet.  [#]_
 
+If a source package is in the *non-free* archive area, then each of the
+binary packages that it produces must also be in the *non-free* archive
+area.
+
 .. _s-pkgcopyright:
 
 Copyright considerations
-- 
2.33.0

Reply via email to