Here's a draft of a ballot for #681419. Despite the form, I think this is probably still more of a discussion document; Ian indicated that he'd like the opportunity to discuss this by e-mail before voting, and I don't know if I've fully captured all the positions and arguments.
Ian, I've taken the liberty of drafting option B in an attempt to describe what I understand as your position, but I'm sure you can do a better job of it. I've committed this to our git repository as 681419_free_non_free_dependencies/cjwatson_draft.txt. 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. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org