Re: Bug#353277: ndiswrapper in main
Adam McKenna <firstname.lastname@example.org> writes:
> The question is not what problems it would cause. The problems are side
> effects. It should stay in main because it is free software that is able to
> be used by at least some subset of our users, without any non-free software.
Ok, this seems to be a simple factual question, and I have been unable
to see the answer despite careful reading of the thread and the bug
What is the subset of our users which would find ndiswrapper useful,
without the use of free software? I have heard some say that there
are no free drivers around for ndiswrapper to wrap. If that's true,
then wouldn't that make the subset in question the empty set? Or is
there some use to ndiswrapper without a driver to wrap with it?
Or, perhaps it's not true that there are no free drivers for it. The
claim was also made that there was a single free driver out there for
use with ndiswrapper, but others claimed that the hardware in question
is already supported, and better, without the use of that driver. I
don't know whether this is true, but if it is true, I would appreciate
hearing why that should be treated differently than there being no
such free driver at all.
(BTW: I have no problem saying that a thing is in contrib while it can
support only non-free software, and as soon as a realistic case of it
supporting free software comes along, it moves into main. Some people
seemed to have been assuming in this thread that this is a ludicrous
possibility, but it seems perfectly natural to me.)
> In addition, there are other potential issues with having it in contrib, one
> of which is inaccessibility to the installer. The overall effect is
> decreased utility for our users.
Once again, this is not a real issue. This is a bug in the installer,
and not a categorization mistake. If the installer is fixed, there is
no decreased utility of this sort for putting the package in contrib.
So let's pretend that the installer bug has been fixed.
Moreover, the standards for contrib do not (at present) make any
reference to utility or convenience. Perhaps this should be changed,
but I'm assuming that we keep the standards alone. (I make this
presumption only because the argument seems to be that ndiswrapper
belongs in main under the *current* standards, and not some
hypothetical improved standards.)