From 923daf9aaa689e924f3cbd136fa1090b2db6fef7 Mon Sep 17 00:00:00 2001 From: Colin Watson Date: Thu, 26 Sep 2013 16:48:23 +0100 Subject: [PATCH] fold in Ian's changes to option B for #681419 --- .../cjwatson_draft.txt | 53 ++++++++++++------- 1 file changed, 34 insertions(+), 19 deletions(-) diff --git a/681419_free_non_free_dependencies/cjwatson_draft.txt b/681419_free_non_free_dependencies/cjwatson_draft.txt index 13e4040..f07b7d1 100644 --- 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. -- 2.39.5