Re: Bug#353277: ndiswrapper in main
On 2/28/06, Anthony Towns <aj@azure.humbug.org.au> wrote:
> Okay, so I'll vote against both these.
Understood.
But I'd appreciate it if you could refine your arguments some more:
> After the discussions so far, I'm inclined towards the following two views
> of our policy on this:
>
> * first, that dependencies are one way -- programs depend on
> libraries, but libraries don't depend on the programs that use
> them;
I don't think that can really be true in the general case. For example,
we have the "base system" where pretty much everything in base has
a mutual dependency on pretty much everything else in base.
> * and second, that programs that only operate when interacting with
> non-free programs, whether over the net or via data files, aren't
> considered to depend on those non-free programs.
The issue I thought was important in the context of ndiswrapper was: what
software has to be installed on the debian system for people to use
ndiswrapper?
I'm not sure that this general statement really refutes that position.
> That means that:
>
> (a) libraries that aren't used by any DFSG-free programs are okay
> for main, so packages like libamstd-ruby1.8 that provide a library
> that no package happens to use are still fine
If the issue is "what needs to be installed for people to use libamstd-ruby1.8
the way it's typically used" would there be any missing packages?
> (b) ndiswrapper is okay for main (non-free drivers depend on it, and
> there are no free packages that depend on it, but it does not depend
> on anything non-free)
I'm not saying you're wrong here, but I think we should find better examples
where the "what needs to be installed" logic falls down, if we're going to
go this route.
> (c) free viewers/players for proprietary formats (Word documents,
> mp3 players, etc) are okay for main
While this is true, I you're talking about content which can be
fetched by any user on a typical system. There's no need for
the system administrator to install anything here.
> (d) free clients for proprietary protocols (for which there is no
> free server) are okay for main
Again, in the typical case there's no need for the administrator
to install anything.
> All of which are (ttbomk) existing practice.
I agree, and I think you're drawing the line in an appropriate place,
for the most part.
But I think this case -- <<where root privileges are needed, in order to
install non-free software, in order to make the package work the way that
people typically think of as using it>>... I think this case is on the wrong
side of that line.
> It would be consistent to invert either principle; but I don't think it
> would be practical to remove packages that would be classified under
> either (a) or (c) from main, and I think the relationship between (a)
> and (b) and (c) and (d) are pretty strong, to the point I can't really
> see why it would be fair to drop one without also dropping the other.
Could you comment directly on the issue I've <<bracketed>> above?
Thanks,
--
Raul
Reply to: