[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 reasons. > 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 ndiswrapper. 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. Peter
signature.asc
Description: Digital signature