681419_free_non_free_dependencies/cjwatson_draft.txt

   1   Whereas:
   2
   3   1. The Debian Policy Manual states (§2.2.1) that packages in main
   4      "must not require or recommend a package outside of main for
   5      compilation or execution".  Both "Depends: package-in-non-free" and
   6      "Recommends: package-in-non-free" clearly violate this requirement.
   7      The Technical Committee has been asked to determine whether a
   8      dependency of the form "package-in-main | package-in-non-free"
   9      complies with this policy requirement, or whether virtual packages
  10      must instead be used to avoid mentioning the non-free alternative.
  11
  12   2. Both options have the following effects in common, meeting the
  13      standard that main should be functional and useful while being
  14      self-contained:
  15
  16     (a) Package managers configured to consider only main will install
  17         package-in-main.
  18
  19     (b) Package managers configured to consider both main and non-free
  20         will prefer to install package-in-main, but may install
  21         package-in-non-free instead if so instructed, or if
  22         package-in-main is uninstallable.
  23
  24     (c) If package-in-non-free is already installed, package managers
  25         will proceed without installing package-in-main.
  26
  27   3. The significant difference between these two options is that the
  28      former makes the non-free alternative visible to everyone who
  29      examines the dependency relationship, while the latter does not.
  30
  31 A 4. Merely mentioning that a non-free alternative exists does not
  32 A    constitute a recommendation of that alternative.  For example, many
  33 A    free software packages state quite reasonably that they can be
  34 A    compiled and executed on non-free platforms.
  35 A
  36 A 5. Furthermore, virtual packages are often a clumsy way to express
  37 A    these kinds of alternatives.  If a package happens to require any
  38 A    of several implementations of a facility that have a certain
  39 A    option, then it can either depend on suitable alternatives
  40 A    directly, or its maintainer can first attempt to have fine-grained
  41 A    virtual packages added to each of the packages they wish to permit.
  42 A    In some cases this may be appropriate, but it can easily turn into
  43 A    quite a heavyweight approach.
  44 A
  45 A Therefore:
  46 A
  47 A 6. The Technical Committee resolves that alternative dependencies of
  48 A    the form "Depends: package-in-main | package-in-non-free" are
  49 A    permissible in main, and do not constitute a violation of the
  50 A    policy clause cited in point 1.
  51 A
  52 A 7. We nevertheless recommend that packages in main consider carefully
  53 A    whether this might cause the inadvertent installation of non-free
  54 A    packages due to conflicts, especially those with usage
  55 A    restrictions.
  56
  57 B 4. Listing a package explicitly in a dependency relationship implies
  58 B    to users that the maintainer has taken steps to confirm its
  59 B    suitability, and thus amounts to a recommendation, even if only as
  60 B    one of several possibilities.
  61 B
  62 B 5. There is a substantial risk that a secondary dependency on a
  63 B    package in non-free will cause that package to be installed by
  64 B    default when the primary dependency is uninstallable.
  65 B
  66 B 6. Virtual packages are a suitable existing mechanism for packages to
  67 B    declare the set of abstract features they provide, and allow
  68 B    packages in main to depend on such abstract features without
  69 B    needing to name every (free or non-free) alternative.  They should
  70 B    nevertheless name at least one free preferred alternative, so that
  71 B    the package management system has appropriate defaults.
  72 B
  73 B Therefore:
  74 B
  75 B 7. The Technical Committee resolves that alternative dependencies of
  76 B    the form "Depends: package-in-main | package-in-non-free"
  77 B    constitute a violation of the policy clause cited in point 1.
  78 B
  79 B 8. We recommend that affected packages consider the use of virtual
  80 B    packages instead.  When doing so, they should specify a real
  81 B    package in main as the first alternative, e.g. "Depends:
  82 B    package-in-main | virtual-interface".