>>>>> "Eduard" == Eduard Bloch <[EMAIL PROTECTED]> writes:
Eduard> And I have never understood why the apt-setup questions Eduard> for contrib and non-free have been put into the same Eduard> dialog. The only possible reason is that the users that Eduard> have deliberately decided to not use non-free software Eduard> (because of "political" reasons) should never come in Eduard> touch with it and therefore all possible ways that may Eduard> lead to the "dark side" should be hidden. OTOH the last Eduard> action is already a kind of limiting the freedom of Eduard> choice. And if not (eg. is explained as something else, Eduard> political correctness or whatever) then it still means Eduard> making life or users harder and is a violation of Eduard> DSFG. Pushing users for ideological reasons sucks. I believe installer packages for non-free software still go in contrib, because they are considered GPL compliant. So if you want to be sure you won't accidently get confused with non-free software (I have done so from time to time), this can be achieved by eliminating all non-free software from the search results produced by "apt-cache search". This requires eliminating contrib as well as nonfree. Example, in sarge: flashplugin-nonfree and quake2-data is in contrib. There are also other suspicious packages in sarge maintained by the GA group, eg. acl-installer, and int-fiction-installer. 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. On the other hand, the possibility exists that somebody is using ndiswrapper, either now or in the future with entirely DFSG software. 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. Whether this means ndiswrapper should go in main, flashplugin-nonfree should go in non-free, or some other solution, I am undecided. Note: [1] One way, I think, of looking at ndiswrapper is that it is a set of DFSG hooks to allow integration with add-on nonfree software. I believe there are similar hooks in the Linux kernel. 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. Why should it be any different if you split the hooks out into a separate user space and separate kernel space package? 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? 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? I am not providing an opinion here, but I didn't notice these issues being discussed earlier. back to your regular program... -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]