Bug#681419: Alternative main->non-free dependencies text
On Thu, Jun 27, 2013 at 04:01:21PM +0100, Ian Jackson wrote:
> So I promised to write up my position on this. Sorry it's taken so
> long.
Thanks for putting this together. I've merged it with Stefano's
comments and pushed it to the debian-ctte repository [1].
I suggest that we proceed to a vote on this soon, as this has gone on
for a long time (largely my fault); I'll ask for further thoughts at the
TC IRC meeting today, and probably call for a vote over the next few
days.
> Firstly, I think it's very disingenous to say that putting
> "Recommends: foo | bar" is not a recommendation by Debian of bar.
> Mentioning in a positive way such specific non-free software is
> clearly an endorsement, no matter any official position statements
> claiming that it isn't.
>
> The fact that the word "Recommends" is used is not just a matter of
> "invisible" package metadata. It appears in many places
> (packages.d.o, package manager UIs, etc.) And there are no "hygiene"
> rules about when alternative names should be displayed, so that (for
> example) a user who choses not to enable non-free isn't presented
> (say when they try to remove "foo") with a suggestion to install a
> non-free program.
I tend to agree with the statements above.
> It is utterly trivial to use neutrally-named virtual packages instead,
> in this case. There are no cases of versioned dependencies.
My main concern is the cases where it isn't utterly trivial. There are
two issues here.
Firstly, while I think using a virtual package is often the right thing
to do, we shouldn't ignore the fact that it can turn a simple element in
your own package's control file into having to go and get another
maintainer to add a Provides, which multiplies up the effort involved by
quite a bit. Of course the problem of obstructive or inactive
maintainers can be handled in the usual ways, but it's still a chunk of
extra effort.
Secondly, the features involved here are often pretty fine-grained. One
of the cases mentioned in #587279 was unrar, and it wouldn't surprise me
if different implementations of that kind of archival tool had problems
such as "fails to support particular versions of archives commonly used
by my users" or "fails to support a particular command-line option". We
could well end up with virtual packages like
"unrar-supporting-option-v"; I'm not sure if you will agree, but this
feels rather over-the-top to me. It also seems perverse that this would
require the maintainers of the free alternatives to do work (or ignore
bugs until somebody else does the work) to add metadata declaring that
they support this or that feature that the non-free alternative doesn't,
for the sole benefit of yet another package.
Perhaps I'm imagining problems that won't exist, but it seems as though
this puts the effort in quite the wrong places. If we had a model where
it was expected that all developers collaboratively maintained all
packages, then it would be different, but I'm not sure we're quite there
yet ...
(Of course, there is the alternative of not mentioning the non-free
alternatives at all; and I suppose that's a valid position in line with
the dedication of the project to free software. But the reasons we
provide non-free at all stem from the project's other primary priority,
and when maintainers use alternative dependency relationships it's often
because they have users who find that only a non-free package meets
their needs; and if it conflicts with a similar free package, as is
often the case when they provide similar interfaces, then they can wind
up being rather more inconvenienced than is necessary.)
> We aren't (or at least I'm not) proposing to make these cases a
> release-critical bug. It should however be a bug that should be
> recorded in the BTS, and which interested parties can work on to
> improve make Debian better promote software freedom.
This, on the other hand, mollifies me considerably with regard to your
option; it implies that in the cases where introducing a virtual package
actually isn't trivial, a developer might decide that it is better to
temporarily introduce a bug, in the same way that that is sometimes an
appropriate thing to do elsewhere.
So, with your addition of "non-release-critical", I'd be prepared to
support your option B (i.e. I believe my vote would be B A F), and we
can see what the practical effects on the archive end up being.
> (I think a weaker version of the same argument applies to Suggests. I
> haven't seen statistics about how many Suggests we have from main to
> non-free. If there are lots then it would make sense to implement
> Enhances instead. But at this stage I don't propose to argue about
> Suggests.)
We do of course have Enhances, and it's fairly widely used, although out
of 752 Enhances fields in the archive there are only 33 found in
packages in contrib or non-free. And of course unsatisfied Suggests for
various reasons are quite widespread.
But I think this is moot as far as the question we've been asked is
concerned, and indeed we don't need to debate it at this stage.
[1] http://anonscm.debian.org/gitweb/?p=collab-maint/debian-ctte.git;a=commitdiff;h=923daf9aaa689e924f3cbd136fa1090b2db6fef7
--
Colin Watson [cjwatson@debian.org]
Reply to: