draft for #681419

diff --git a/681419_free_non_free_dependencies/cjwatson_draft.txt b/681419_free_non_free_dependencies/cjwatson_draft.txt
new file mode 100644 (file)
index 0000000..97a579c
--- /dev/null
+++ b/681419_free_non_free_dependencies/cjwatson_draft.txt
@@ -0,0 +1,78 @@
+  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 dependency relationship implies
+B    to users that the maintainer has taken steps to confirm its
+B    suitability, and thus amounts to a recommendation, even if only as
+B    one of several possibilities.
+B
+B 5. There is a substantial risk that a secondary dependency on a
+B    package in non-free will cause that package to be installed by
+B    default when the primary dependency is uninstallable.
+B
+B 6. Virtual packages are a suitable existing mechanism for packages to
+B    declare the set of abstract features they provide, and allow
+B    packages in main to depend on such abstract features without
+B    needing to name every (free or non-free) alternative.
+B
+B Therefore:
+B
+B 7. The Technical Committee resolves that alternative dependencies of
+B    the form "Depends: package-in-main | package-in-non-free"
+B    constitute a violation of the policy clause cited in point 1.
+B
+B 8. We recommend that affected packages consider the use of virtual
+B    packages instead.