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 > > 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 8. We recommend that affected packages consider the use of virtual > > B packages 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 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 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". > 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