As previously agreed in the IRC meeting, I call for votes on this question
with the following ballot options:
A non-free packages as non-default alternatives should not be prohibited in main
B non-free packages should always be prohibited in package dependencies for main
FD
Whereas:
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
self-contained:
(a) Package managers configured to consider only main will install
package-in-main.
(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.
A 4. Merely mentioning that a non-free alternative exists does not
A constitute a recommendation of that alternative. For example, many
A free software packages state quite reasonably that they can be
A compiled and executed on non-free platforms.
A
A 5. Furthermore, virtual packages are often a clumsy way to express
A these kinds of alternatives. If a package happens to require any
A of several implementations of a facility that have a certain
A option, then it can either depend on suitable alternatives
A directly, or its maintainer can first attempt to have fine-grained
A virtual packages added to each of the packages they wish to permit.
A In some cases this may be appropriate, but it can easily turn into
A quite a heavyweight approach.
A
A Therefore:
A
A 6. The Technical Committee resolves that alternative dependencies of
A the form "Depends: package-in-main | package-in-non-free" are
A permissible in main, and do not constitute a violation of the
A policy clause cited in point 1.
A
A 7. We nevertheless recommend that packages in main consider carefully
A whether this might cause the inadvertent installation of non-free
A packages due to conflicts, especially those with usage
A restrictions.
B 4. Listing a package explicitly in a Recommends field clearly states
B that we are recommending it, even if the package appears only as
B a secondary alternative. Official statements to the contrary are
B ineffective at preventing readers from getting the impression
B that packages mentioned in "Recommends" are being recommended.
B
B 5. One of the main goals of the Debian Project is to promote
B software freedom. Promoting software freedom includes avoiding
B promoting non-free software, at the very least when it's
B straightforward to do so.
B
B 6. The alternative, of using a neutrally-named virtual package, is
B only slightly inconvenient. Virtual packages are a suitable
B existing mechanism for packages to declare the set of abstract
B features they provide, and allow packages in main to depend on
B such abstract features without needing to name every (free or
B non-free) alternative. They should nevertheless name at least one
B free preferred alternative, so that the package management system
B has appropriate defaults.
B
B 7. There are not very many dependencies which need to be fixed.
B In any case, changing the policy (without making this a release
B critical bug) doesn't constitute a demand that the existing
B maintainers do this work. However, it is needed to ensure that
B those who do want to do the work can get their changes accepted.
B
B Therefore:
B
B 8. The Technical Committee resolves that alternative dependencies of
B the form "Depends: package-in-main | package-in-non-free"
B constitute a non-release-critical violation of the policy
B clause cited in point 1.
B
B 9. When it is necessary to provide a reference in a Depends or
B Recommends from main to non-free, this should be done via a
B neutrally named virtual package. Packages depending on such a
B virtual package should specify a real package in main as the first
B alternative, e.g. "Depends: package-in-main | virtual-interface".
B
B 10. The Technical Committee requests that the policy editors make
B an appropriate clarification to the policy documents.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature