Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Michael Poole <mdpoole@troilus.org>]

Josselin Mouette writes:

> Le samedi 18 février 2006 à 09:59 -0500, Michael Poole a écrit :
> > Anthony Towns writes:
> > 
> > > But even if that weren't the case, nasm is an assembler -- it doesn't
> > > rely on assembler code to do anything useful, its purpose is to translate
> > > assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to
> > > allow existing drivers to run on Linux.
> > 
> > This apparently means that you object to translation at the binary
> > level but not translation at the source level.  I guess that's
> > reasonable in a general sense, it's just not a distinction that policy
> > or the DFSG makes.
> 
> Come on, please stop arguing with random, unsuited comparisons, and use
> common sense : what's the purpose of ndiswrapper without non-free
> drivers to use it on? We've always put things of the like in contrib,
> and if we stop doing it, we can remove contrib entirely.

What's the purpose of an assembler without assembly code to use it on?
Despite Anthony's claim, I see no packages that can use nasm out of
the box, which means it needs software not in main to perform its
intended use (which seems to be the objection to ndiswrapper).

If you want to move ndiswrapper to contrib, I expect the next step is
to do the same to libflash, for the same reasons.  Next: natively
compile all Java packages in main and move interpreter and compilers
for Java bytecode to contrib.  After all, the point of Java is to
allow the running of non-free software.  Mono and DotGNU would get the
same treatment.  Right?

Michael Poole