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 [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
