[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#353277: ndiswrapper in main

[Brian May]
> I think these should belong in a separate category then ndiswrapper,
> because, unlike ndiswrapper, they are not even "complete" packages
> without non-free software, and this will never change for the
> lifetime of the installer package.

Never underestimate the Debian universe's collective ability to
contrive a justification for something.  It could be said that an
installer for some random bits that can't even be carried on non-free
should actually go in main because, in some hypothetical alternate
universe future scenario, somebody _might_ reimplement the non-free
component in a free way, and furthermore, it might make sense to
install it using the scripts in the wrapper package rather than
packaging it natively.  Perhaps the developer of the free replacement
would like to have the wrapper package on his system in order to
facilitate testing.

> Even if nobody does this, it is still possible to integrate
> ndiswrapper with free software (such as debian-installer)[1]. The
> same thing cannot be said (IMHO) for an installer package.

Eh?  Why not?  Why wouldn't you be able to integrate an installer
package with other free software?

And, speaking of d-i, here's another thing I've been unable to
understand.  Someone please enlighten me, because I feel sure I must be
missing something:

What possible use would it be to integrate ndiswrapper into
debian-installer?  Wouldn't the user _still_ have to provide a Windows
driver in some format usable by ndiswrapper?  Wouldn't that still have
to come from some external source, like a web site or a floppy disk?
And if so, why would it be a hardship to get ndiswrapper from an
external source at the same time?

I can understand the appeal of having ndiswrapper on the installer
image, but only if the image also has drivers to use with it.  Are we
talking about CIPE again?  Is CIPE useful for an installer?

> Some of these hooks can only be used by non-free software
> (e.g. uploading of nonfree firmware). This doesn't make the kernel
> contrib.

No, because the kernel as a whole can do a great many things beyond
just loading firmware.  If the kernel existed only for that one
purpose, its status would be just as controversial, for the same

> Would kernel code for uploading firmware suddenly become contrib if
> you split it out from the kernel source and made it a compilable
> module? Why so/not?

Yes, because at that point the separate package isn't useful on its
own.[*]  The kernel as a whole is useful on its own.

[*] Note also that you may have chosen a bad example.  Free firmware
    _does_ exist - see the aic7xxx and sym53c8xx drivers.  Actual
    firmware source code, and miniature assemblers for same, are
    shipped in the standard kernel.  In other words, Adaptec and NCR,
    _many_ years ago, proved that those who say DFSG-compliant firmware
    is impossible or impractical are wrong.  However ... I don't know
    whether the aic7xxx and sym53c8xx drivers have been updated to be
    able to load firmware via the kernel hooks, or whether they still
    just have it built into the module binaries.

The rule here is that if something is useful without non-free software,
but _incidentally_ can also make use of non-free software, nobody has a
problem with it in main.  If the only reason for something to exist is
to use it with non-free software, that's where the arguments come in.

Remember that main / contrib is not an issue of whether a given package
is free.  The only issue is whether the package is useful without
non-free software.

> Would the situation be any different if there was a package in main
> that depended on ndiswrapper-utils, but made use of such non-free
> drivers optional? If ndiswrapper moved to contrib would this package
> have to move to?

No, package foo can stay in main, because it wouldn't be a hard Depends
relationship (or it shouldn't be, anyway), it would be a Suggests or
possibly Recommends, depending on how common it is to use foo without

Actually, I'm not certain whether packages in main are allowed to
Suggest packages outside main.  If not, the usual workaround is for
ndiswrapper to instead declare an Enhances relationship on foo.  The
semantics are similar.  Either way, if foo still does useful things for
some users without ndiswrapper or its drivers, it can perfectly well go
in main.


Attachment: signature.asc
Description: Digital signature

Reply to: