resolved_issues/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 Recommends field clearly states
  58 B    that we are recommending it, even if the package appears only as
  59 B    a secondary alternative.  Official statements to the contrary are
  60 B    ineffective at preventing readers from getting the impression
  61 B    that packages mentioned in "Recommends" are being recommended.
  62 B
  63 B 5. One of the main goals of the Debian Project is to promote
  64 B    software freedom.  Promoting software freedom includes avoiding
  65 B    promoting non-free software, at the very least when it's
  66 B    straightforward to do so.
  67 B
  68 B 6. The alternative, of using a neutrally-named virtual package, is
  69 B    only slightly inconvenient.  Virtual packages are a suitable
  70 B    existing mechanism for packages to declare the set of abstract
  71 B    features they provide, and allow packages in main to depend on
  72 B    such abstract features without needing to name every (free or
  73 B    non-free) alternative.  They should nevertheless name at least one
  74 B    free preferred alternative, so that the package management system
  75 B    has appropriate defaults.
  76 B
  77 B 7. There are not very many dependencies which need to be fixed.
  78 B    In any case, changing the policy (without making this a release
  79 B    critical bug) doesn't constitute a demand that the existing
  80 B    maintainers do this work.  However, it is needed to ensure that
  81 B    those who do want to do the work can get their changes accepted.
  82 B
  83 B Therefore:
  84 B
  85 B 8. The Technical Committee resolves that alternative dependencies of
  86 B    the form "Depends: package-in-main | package-in-non-free"
  87 B    constitute a non-release-critical violation of the policy
  88 B    clause cited in point 1.
  89 B
  90 B 9. When it is necessary to provide a reference in a Depends or
  91 B    Recommends from main to non-free, this should be done via a
  92 B    neutrally named virtual package.  Packages depending on such a
  93 B    virtual package should specify a real package in main as the first
  94 B    alternative, e.g. "Depends: package-in-main | virtual-interface".
  95 B
  96 B 10. The Technical Committee requests that the policy editors make
  97 B    an appropriate clarification to the policy documents.