On Thu, Mar 02, 2006 at 07:27:41PM -0500, Raul Miller wrote: > On 3/2/06, Steve Langasek <vorlon@debian.org> wrote: > > > With that in mind, policy on contrib says that contrib is for > > > "wrapper packages or other sorts of free accessories for non-free programs." > > > http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib > > > And I think ndiswrapper is "a sort of free accessory for non-free programs." > > Ok. Would you say the same thing about a free library that implements an > > API/ABI which is primarily of interest to users of pre-existing non-free > > software? If not, why is one an "accessory" and the other not? > That's a good question. > The way I'm currently thinking: If there are debian packages that you > can use in WINE, or if it has some functionality that makes it useful > in and of itself, then it belongs in main. Otherwise it belongs in > contrib. So... $ zcat dists/unstable/main/binary-i386/Packages.gz | grep-dctrl -FDepends -sPackage wine Package: libwine-alsa Package: libwine-arts Package: libwine-capi Package: libwine-cms Package: libwine-dev Package: libwine-esd Package: libwine-gl Package: libwine-jack Package: libwine-ldap Package: libwine-nas Package: libwine-print Package: libwine-twain Package: wine Package: wine-utils $ We have zero packages in main that use wine, except for the wine-utils package itself that contains various free "toy" implementations of common Windows utilities -- no more useful alone than wine itself is. By your reasoning, does this mean wine should be moved to contrib? Or is there some "in and of itself" usefulness that applies here but not in the case of ndiswrapper? > For example, if there's free software being developed against > WINE (as a UI, or whatever) then that's sufficient reason right > there, to leave it in main. Counting the toy utilities that are bundled with wine, or only other free software? I don't know of anyone developing free software against wine. I've used it to develop *non-*free software; I could *imagine* someone developing free software against wine, but I can also *imagine* someone developing free software against ndiswrapper. > I'm willing to hear reasons why this reasoning is wrong, but if we're > going to go that route I think we to think those reasons through and > come up with some suggested policy that distinguishes between the WINE > case and the cases that belong in Contrib. Well, I would note that at this point, we seem to no longer be talking about confirming existing policy; if we were, I would expect that more weight would be given to AJ's proposed criteria, since as an ftpmaster he's pretty much the resident authority on what this de facto policy is. > > > Perhaps it could be phrased that ndiswrapper has a need for the presence > > > of some software which is not available in debian main. > > If we didn't ship any free software built around the Motif API, would this > > mean lesstif had a "need for the presence of some software which is not > > available in Debian main"? > I've been suggesting that the answers to these questions depend on > our best understanding of how our users use the software. > If it's built and deployed for people to develop against, that's one > thing. > If it's not documented and supported for development work, and no > one is developing against it, and it's only being used by people > who want to install something that's not free, then that's an > entirely different situation. But there's plenty of documentation for writing NDIS drivers, just as there is for writing Windows applications. AFAIK, you can develop NDIS drivers on Debian using mingw just as you can develop Windows applications this way. Doesn't that leave as the only distinction between wine and ndiswrapper the theory that one is interesting to free software developers and the other isn't? Does this mean wine and ndiswrapper belong in the same section, or do we then shuffle packages back and forth between contrib and main depending on the results of surveys of some kind? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature