Bug#681419: marked as done (Alternative dependencies on non-free packages in main)
Your message dated Fri, 31 Oct 2014 14:55:02 -0700
with message-id <20141031215502.GA26165@teltox.donarmstrong.com>
and subject line Re: Alternative dependencies on non-free packages in main: Call for Votes
has caused the Debian Bug report #681419,
regarding Alternative dependencies on non-free packages in main
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact firstname.lastname@example.org
Debian Bug Tracking System
Contact email@example.com with problems
--- Begin Message ---
- To: Debian Bug Tracking System <firstname.lastname@example.org>
- Subject: Alternative dependencies on non-free packages in main
- From: Russ Allbery <email@example.com>
- Date: Thu, 12 Jul 2012 20:45:31 -0700
- Message-id: <firstname.lastname@example.org>
As a Debian Policy delegate, I'm delegating to the Technical Committee
the resolution of bugs #587279 and #616462.
The current Policy wording is:
In addition, the packages in main
* must not require or recommend a package outside of main
for compilation or execution (thus, the package must not declare
a "Pre-Depends", "Depends", "Recommends", "Build-Depends", or
"Build-Depends-Indep" relationship on a non-main package),
The question at issue in these bugs is whether it is permissible for
a package in main to declare a non-default alternative dependency on
a package in non-free. In other words, may a package in main have a
Depends: foo | foo-nonfree
(I believe that the question of whether "foo-nonfree | foo" should be
allowed is not at issue and that the consensus is that it's not
permitted. However, the Technical Committee can certainly open that
discussion if desired.)
Please see the bugs cited above for the complete earlier discussion.
(Note that the end of #587279 has some off-topic discussion of the
exact meaning of "require or recommend a package" that's not at issue
in this bug. I don't think the requested bug about that issue was
ever filed, so I'm inclined to not consider it an issue currently.)
--- End Message ---
--- Begin Message ---
- To: email@example.com
- Subject: Re: Alternative dependencies on non-free packages in main: Call for Votes
- From: Don Armstrong <firstname.lastname@example.org>
- Date: Fri, 31 Oct 2014 14:55:02 -0700
- Message-id: <20141031215502.GA26165@teltox.donarmstrong.com>
- In-reply-to: <20140803015641.GA3336@virgil.dodds.net>
- References: <20140803015641.GA3336@virgil.dodds.net>
A,B,FD: (6) Steve, Russ, Bdale, Keith, Don, Andreas
B,A,FD: (2) Ian, Colin
A is the CTTE decision:
1. The Debian Policy Manual states (�2.2.1) that packages in main
"must not require or recommend a package outside of main for
compilation or execution". Both "Depends: package-in-non-free" and
"Recommends: package-in-non-free" clearly violate this requirement.
The Technical Committee has been asked to determine whether a
dependency of the form "package-in-main | package-in-non-free"
complies with this policy requirement, or whether virtual packages
must instead be used to avoid mentioning the non-free alternative.
2. Both options have the following effects in common, meeting the
standard that main should be functional and useful while being
(a) Package managers configured to consider only main will install
(b) Package managers configured to consider both main and non-free
will prefer to install package-in-main, but may install
package-in-non-free instead if so instructed, or if
package-in-main is uninstallable.
(c) If package-in-non-free is already installed, package managers
will proceed without installing package-in-main.
3. The significant difference between these two options is that the
former makes the non-free alternative visible to everyone who
examines the dependency relationship, while the latter does not.
4. Merely mentioning that a non-free alternative exists does not
constitute a recommendation of that alternative. For example, many
free software packages state quite reasonably that they can be
compiled and executed on non-free platforms.
5. Furthermore, virtual packages are often a clumsy way to express
these kinds of alternatives. If a package happens to require any
of several implementations of a facility that have a certain
option, then it can either depend on suitable alternatives
directly, or its maintainer can first attempt to have fine-grained
virtual packages added to each of the packages they wish to permit.
In some cases this may be appropriate, but it can easily turn into
quite a heavyweight approach.
6. The Technical Committee resolves that alternative dependencies of
the form "Depends: package-in-main | package-in-non-free" are
permissible in main, and do not constitute a violation of the
policy clause cited in point 1.
7. We nevertheless recommend that packages in main consider carefully
whether this might cause the inadvertent installation of non-free
packages due to conflicts, especially those with usage
Don Armstrong http://www.donarmstrong.com
If I had a letter, sealed it in a locked vault and hid the vault
somewhere in New York. Then told you to read the letter, thats not
security, thats obscurity. If I made a letter, sealed it in a vault,
gave you the blueprints of the vault, the combinations of 1000 other
vaults, access to the best lock smiths in the world, then told you to
read the letter, and you still can't, thats security.
-- Bruce Schneier
--- End Message ---