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
> > 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 [cjwatson@debian.org]
Reply to: