Sorry for the delays in writing this up. Of the two options presented at <http://anonscm.debian.org/gitweb/?p=collab-maint/debian-ctte.git;a=blob;f=681419_free_non_free_dependencies/cjwatson_draft.txt;h=f07b7d1c25adeb69d113640b1a5a900923cc0621;hb=HEAD>, I am unequivocally in favor of option A and against option B. So I promised to explain why, which I'm now getting around to doing. I believe the *spirit* of the policy requirement is twofold: - if a package is in main, it must be possible to install it without it pulling in any packages from outside of main, even if the Debian contrib and non-free archives are enabled on the system - if a non-free alternative to a component exists, and the user has chosen to use that non-free component for whatever reason, we should make every reasonable effort to make this work well for the user. I'm sure the first part is something we all agree on, and only the second point seems to be contentious insofar as we are drawing different lines with regards to "reasonable effort". Consider the hypothetical packages gfoo, foo, and unfoo, where the foo package is not only non-free, it's not even redistributable; it is made available only from an upstream website. And we have no effective communication channel for getting bugfixes made to the packaging of foo. But because of certain compelling features, a number of our users choose to install it (even doing so over download channels that are easily subject to MITM... but that's another story). Now, unfoo is a free reimplementation that provides the same overall interfaces as foo (including executable paths). Since unfoo is in Debian and we control it, we can of course make unfoo Conflicts/Replaces/Provides foo. And gfoo is a GUI frontend to /usr/bin/foo, and therefore declares that it Depends: unfoo. Since we want users to be able to distinguish between the free and non-free implementations, we don't want unfoo to be named 'foo'. And we don't want gfoo to Depend on 'foo', which could cause the package manager to pull in the non-free implementation automatically when it shouldn't. So we must have 'Depends: unfoo'. But if gfoo can't declare 'Depends: unfoo | foo' because foo is a real rather than virtual package, then how can gfoo support those users who choose to install the non-free foo? We know that we don't control the foo package; is the desired outcome here that installing 'foo' must remove 'gfoo'? And if we accept that this is not the desired outcome (which I do), and that gfoo should therefore be allowed to declare 'Depends: unfoo | foo', how can we justify a stronger restriction than this for non-free software that *is* in the Debian archive than for non-free software that *isn't*? So I submit that this is not an area where Policy should be enforcing a prohibition on the contents of non-default alternatives. We might recommend the use of virtual packages, but should not micromanage our developers with an outright prohibition. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature