Bug#681419: Proposed ballot for free/non-free dependencies question
Hi Colin, everyone, On Thursday 25 October 2012 09:05:30 Colin Watson wrote: 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. [...] 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. I think I must note something that I find rather important, before it is too late: the current tech-ctte discussion revolves only around non-free. My proposed wording on the policy bug, and later Russ' wording that I seconded, both talk about packages *not in main*. To spell it out: the original discussion in the policy bug report also covered packages in contrib while the current discussion doesn't. Oh, and while I personally disagree with the use of virtual packages in the way proposed by option B of the ballot, I think it should make it clear that the virtual package name must not be the name of a real package. That is, I ask the comittee to explicitely disallow cases such as the example of package foo in http://bugs.debian.org/cgi- bin/bugreport.cgi?msg=17;bug=587279 Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681419: Proposed ballot for free/non-free dependencies question
On Fri, Oct 26, 2012 at 11:53:24AM +0200, Stefano Zacchiroli wrote: On Thu, Oct 25, 2012 at 03:05:30PM +0100, Colin Watson wrote: 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. […] B 6. Virtual packages are a suitable existing mechanism for packages to Bdeclare the set of abstract features they provide, and allow Bpackages in main to depend on such abstract features without Bneeding to name every (free or non-free) alternative. […] B 8. We recommend that affected packages consider the use of virtual Bpackages instead. I've a concern about option (B), which I haven't seen addressed in this draft, and that I think it should be addressed before voting (yes, I realize this is a discussion draft, but the sooner the better :-)). It seems to me that the two alternative encodings being discussed have a fundamental difference: 1) package-in-main | package-in-non-free encodes alternative *and* preference for the DFSG-free version 2) virtual-package only encodes alternative between a number of alternatives, some of which are free some of which are not I think you should reword (2), so that the usage of virtual packages is accompanied by an explicit preferences on the free alternative, similarly to what we do for virtual packages when they're used as build dependencies, i.e.: Right. I had this in the back of my mind as something I didn't need to spell out because policy already discusses real alternatives (7.5), but on reflection the wording there is much weaker than I remember and in any case you're correct that this is a disparity between the two ballot options. How about this, which I've committed to our git branch: B 6. Virtual packages are a suitable existing mechanism for packages to Bdeclare the set of abstract features they provide, and allow Bpackages in main to depend on such abstract features without Bneeding to name every (free or non-free) alternative. They should Bnevertheless name at least one free preferred alternative, so that Bthe package management system has appropriate defaults. [...] B 8. We recommend that affected packages consider the use of virtual Bpackages instead. When doing so, they should specify a real Bpackage in main as the first alternative, e.g. Depends: Bpackage-in-main | virtual-interface. I'm a bit on the extreme said perhaps, but I think we should *mandate* that client packages use the package-in-main | alternative and use it before virtual-package in the disjunction. Otherwise we risk having a significant regression. (I'm not sure if it is up to the tech-ctte to mandate this or, say, to the Policy.) I've skimmed briefly through policy, trying to find out whether package managers are supposed to favor package in main over packages in other suites, but haven't find it yet. If there is something like that already, then probably the above is redundant. But even in that case, I'd rather err on the safe side and at least recommend it in the ruling. I would personally not go as far as mandating it, since users who have enabled non-free have already, in my mind, indicated that they find non-free software to be at least minimally acceptable; and I can imagine situations where the technical preference would be for the non-free package because the free alternative is only a rather poor reimplementation, or similar. I do find it more in line with our general principles for packages in main to be preferred for dependency resolution, though, so I went for should. Thanks, -- 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
Bug#681419: Proposed ballot for free/non-free dependencies question
On Thu, Dec 06, 2012 at 09:35:11AM +, Colin Watson wrote: Right. I had this in the back of my mind as something I didn't need to spell out because policy already discusses real alternatives (7.5), but on reflection the wording there is much weaker than I remember and in any case you're correct that this is a disparity between the two ballot options. Thanks for taking my remark into account! I think we're in agreement already , but to stress my main point: - Policy §7.5 explains *how* to provide a real package preference when depending on a virtual package, but does not say *when* to do that. (IIRC there is some provision to do that with build-time dependencies, but I haven't found it with a quick search.) How about this, which I've committed to our git branch: B 6. Virtual packages are a suitable existing mechanism for packages to Bdeclare the set of abstract features they provide, and allow Bpackages in main to depend on such abstract features without Bneeding to name every (free or non-free) alternative. They should Bnevertheless name at least one free preferred alternative, so that Bthe package management system has appropriate defaults. How about: s/at least one free preferred alternative/a default free alternative/ that would be more consistent with the wording of Policy §7.5 (not a big deal, though). [...] B 8. We recommend that affected packages consider the use of virtual Bpackages instead. When doing so, they should specify a real Bpackage in main as the first alternative, e.g. Depends: Bpackage-in-main | virtual-interface. Looks good. Possible s/first/default/ if you apply the suggestion above, for consistency. I do find it more in line with our general principles for packages in main to be preferred for dependency resolution, though, so I went for should. I'm still convinced that a non-free default alternative would not be appropriate. But before trying to argue this point, in an attempt to save us all some discussion time, let me try to side-step it :-) In the initial bug report that brought this issue before the tech-ctte, Russ wrote: (I believe that the question of whether foo-nonfree | foo should be allowed is not at issue and that the consensus is that it's not permitted. However, the Technical Committee can certainly open that discussion if desired.) So it seems that, at least for non-virtual packages, the Policy Team already has consensus that a non-free default alternative is not acceptable. I would find surprising if consensus would be different for virtual packages. Granted, this is my interpretation only, Russ (with his policy editor hat on) would likely know better. As noted, the tech-ctte is certainly free to dig into this specific sub-matter further. But if you're simply looking for a sane default, I think sticking with Policy Team consensus would be entirely appropriate. HTH, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#681419: Proposed ballot for free/non-free dependencies question
Thanks Colin for this draft! On Thu, Oct 25, 2012 at 03:05:30PM +0100, Colin Watson wrote: 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. […] B 6. Virtual packages are a suitable existing mechanism for packages to Bdeclare the set of abstract features they provide, and allow Bpackages in main to depend on such abstract features without Bneeding to name every (free or non-free) alternative. […] B 8. We recommend that affected packages consider the use of virtual Bpackages instead. I've a concern about option (B), which I haven't seen addressed in this draft, and that I think it should be addressed before voting (yes, I realize this is a discussion draft, but the sooner the better :-)). It seems to me that the two alternative encodings being discussed have a fundamental difference: 1) package-in-main | package-in-non-free encodes alternative *and* preference for the DFSG-free version 2) virtual-package only encodes alternative between a number of alternatives, some of which are free some of which are not I think you should reword (2), so that the usage of virtual packages is accompanied by an explicit preferences on the free alternative, similarly to what we do for virtual packages when they're used as build dependencies, i.e.: Package: package-in-main Provide: virtual-package Package: package-in-non-free Provide: virtual-package Package: client1 Depends: package-in-main | virtual-package Package: client2 Depends: package-in-main | virtual-package I'm a bit on the extreme said perhaps, but I think we should *mandate* that client packages use the package-in-main | alternative and use it before virtual-package in the disjunction. Otherwise we risk having a significant regression. (I'm not sure if it is up to the tech-ctte to mandate this or, say, to the Policy.) I've skimmed briefly through policy, trying to find out whether package managers are supposed to favor package in main over packages in other suites, but haven't find it yet. If there is something like that already, then probably the above is redundant. But even in that case, I'd rather err on the safe side and at least recommend it in the ruling. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#681419: Proposed ballot for free/non-free dependencies question
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 Aconstitute a recommendation of that alternative. For example, many Afree software packages state quite reasonably that they can be Acompiled and executed on non-free platforms. A A 5. Furthermore, virtual packages are often a clumsy way to express Athese kinds of alternatives. If a package happens to require any Aof several implementations of a facility that have a certain Aoption, then it can either depend on suitable alternatives Adirectly, or its maintainer can first attempt to have fine-grained Avirtual packages added to each of the packages they wish to permit. AIn some cases this may be appropriate, but it can easily turn into Aquite a heavyweight approach. A A Therefore: A A 6. The Technical Committee resolves that alternative dependencies of Athe form Depends: package-in-main | package-in-non-free are Apermissible in main, and do not constitute a violation of the Apolicy clause cited in point 1. A A 7. We nevertheless recommend that packages in main consider carefully Awhether this might cause the inadvertent installation of non-free Apackages due to conflicts, especially those with usage Arestrictions. B 4. Listing a package explicitly in a dependency relationship implies Bto users that the maintainer has taken steps to confirm its Bsuitability, and thus amounts to a recommendation, even if only as Bone of several possibilities. B B 5. There is a substantial risk that a secondary dependency on a Bpackage in non-free will cause that package to be installed by Bdefault when the primary dependency is uninstallable. B B 6. Virtual packages are a suitable existing mechanism for packages to Bdeclare the set of abstract features they provide, and allow Bpackages in main to depend on such abstract features without Bneeding to name every (free or non-free) alternative. B B Therefore: B B 7. The Technical Committee resolves that alternative dependencies of Bthe form Depends: package-in-main | package-in-non-free Bconstitute a violation of the policy clause cited in point 1. B B 8. We recommend that affected packages consider the use of virtual Bpackages 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
Bug#681419: Proposed ballot for free/non-free dependencies question
Colin Watson cjwat...@debian.org writes: 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. The wording here looks fine to me, FWIW. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
