Bug#587279: Clarify restrictions on main to non-free dependencies
On Sun, 25 Jun 2017 at 14:43:36 -0700, Russ Allbery wrote:
> Here is an updated version of the patch from earlier in this (now very
> long) thread for discussion. I still think this is consistent with
> previous practice and reasonable documentation of what we're currently
> doing.
>
> diff --git a/policy.xml b/policy.xml
> index 7ba5fc0..daf4c3c 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -595,7 +595,9 @@
> <literal>Build-Depends</literal>,
> <literal>Build-Depends-Indep</literal>, or
> <literal>Build-Depends-Arch</literal> relationship on a
> - non-<emphasis>main</emphasis> package),
> + non-<emphasis>main</emphasis> package) unless that package
> + is only listed as a non-default alternative for a package in
> + <emphasis>main</emphasis>,
> </para>
> </listitem>
> <listitem>
>
> If we still can't reach consensus on this, we should probably bump it to
> the Technical Committee for resolution so that this doesn't just sit
> around unresolved forever. (I feel like that happened at some point in
> the past, but it's been so long that my memory is very hazy.)
A TC resolution in 2014 said that
"Depends: package-in-main | package-in-non-free" is acceptable for main,
and not a Policy §2.2.1 violation. What you're doing here is editing
Policy §2.2.1 to make the 2014 TC's interpretation more obviously the
correct one.
References: <http://bugs.debian.org/681419>,
<https://lists.debian.org/debian-devel-announce/2014/10/msg00007.html>
This is certainly not unanimous (the TC vote in 2014 wasn't unanimous
either); but I think there's rough consensus, it matches current
practice, and it's better for Policy to be clear and specific as a
self-contained document, rather than leaving ambiguity in place and
requiring past TC decisions to be consulted for disambiguation. So
I second this patch.
Regards,
S
Reply to: