[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#681419: Alternative dependencies on non-free packages in main: Call for Votes

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


  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.

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 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 Therefore:
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 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 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 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 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 Therefore:
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 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 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

Reply to: