fold in Ian's changes to option B for #681419

diff --git a/681419_free_non_free_dependencies/cjwatson_draft.txt b/681419_free_non_free_dependencies/cjwatson_draft.txt
index 13e404058aba55cff84548cfb9edcd290319f8b7..f07b7d1c25adeb69d113640b1a5a900923cc0621 100644 (file)
--- a/681419_free_non_free_dependencies/cjwatson_draft.txt
+++ b/681419_free_non_free_dependencies/cjwatson_draft.txt
@@ -54,29 +54,44 @@ 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 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. 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 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. 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.  They should
-B    nevertheless name at least one free preferred alternative, so that
-B    the package management system has appropriate defaults.
+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 7. The Technical Committee resolves that alternative dependencies of
+B 8. 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    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 8. We recommend that affected packages consider the use of virtual
-B    packages instead.  When doing so, they should specify a real
-B    package in main as the first alternative, e.g. "Depends:
-B    package-in-main | virtual-interface".
+B 10. The Technical Committee requests that the policy editors make
+B    an appropriate clarification to the policy documents.