On Tue, Feb 28, 2006 at 11:14:22AM +0000, Ian Jackson wrote:
> Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> > 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;
> What, then, is the intended meaning when the policy manual talks about
> `wrappers' for non-free programs ? (Feel free to say that the wording
> is suboptimal and shouldn't be read so closely.)
I believe the intended meaning is to cover installer packages -- ie things
that take a given non-free package and install it on your system for you. Those
packages will break if you don't have the non-free package, and that's where
the dependency lies.
There's a nasty line there, in that if ndiswrapper didn't just provide
an interface for drivers, but actually helped you install them it would
belong in contrib by my reading.
> Also, I think this approach is likely to be a hostage to fortune.
> Software systems are becoming ever more complex and `vertical'
> layering is nowadays sometimes absent - sometimes you can't really say
> which piece of software is `above' or `below' (ie, which depends on
> the other).
If they both work without the other, then there's no dependency; if
neither works without the other, then they mutually depend. I don't think
there's a problem there, though I mightn't have been clear enough above.
> > * 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.
> As I said, I think there is a fundamental distinction between the case
> where the decision to use non-free software is made my the Debian
> user, and where it is made by someone else. Do you agree or
> disagree ? Do you think that's not relevant at all ?
I'm not actually sure what you mean here?
> > 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
> I don't follow the argument here at all. A library can still be
> useful even if nothing in Debian depends on it, either because some
> older Debian package still depends on it, or because a user's own
> software depends on it.
Right. How about if the user's own software is all non-free though? And
if they're the only developer who uses that library, because they wrote
it themselves, and it's not actually all that great? And they distribute
their software far and wide and it's very famous?
In that example, the library is effectively useless without non-free software;
perhaps there are free toys you can use with it, but otherwise, the only point
to it is to run whatever that non-free app is.
Should it go in main? I think "yes" is the only practical answer.
You could say "no", and then we'd have to remove all the libraries no one
actually uses for free software from main -- and that might be a win in
that it'd mean everything in main was "useful", but would be heaps more
trouble than it was worth.
Or you could say "no, but only if we notice it's being used almost
entirely for non-free stuff, rather than just being used for non-Debian
stuff", but I don't think that's a good distinction to draw.
> The purpose of a library is not just to run binaries provided by other
> people; it is also to allow a user to build and then run their own
> programs.
> This is quite different from ndiswrapper unless you're going to claim
> that people are using it for driver development.
No -- I'm going to claim the opposite: that people /aren't/ using a bunch of
the libraries we've got in main for application development.
> Are there any other packages which are in a similar state to
> ndiswrapper by _both_ the criteria I set out and by your asymmetric
> dependency criterion ?
I'm not sure -- I don't use much non-free stuff on Debian. I'd guess that
some of the old libraries we keep around might be in a similar state --
not used for development, and not needed for free software. libdb1-compat,
perhaps.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature