Hi, Peter, Thanks for your very informative response. You've confirmed my understanding that the main/contrib split is not about software freedom at all. I've thus come to the conclusion that it was motivated by the other Debian priority. Please bear with me while I explore the consequences of this conclusion and hopefully provide some food for thought.
Which of these two you think is better for the user: - have software that won't work installed by default on their systems, without much opportunity for acting or even becoming acquantined with the suggested components, taking up disk space and bandwidth (e.g., a kernel containing modules that won't work, even if you install every package in main and contrib). Worse, software that might give the user the impression that something is going to work (module is loaded, reports some progress), but then fail pretty much silently, giving no information to the user as to what the problem is (namely, the lack of Free Software to perform the needed function, and the effective impossibility of developing such Free Software) - have software that will work to the fullest extent possible installed by default (a kernel package containing only modules that don't depend on any package outside main), and split into separate packages any components that couldn't possibly work out of the box, that will document, through dependencies, whatever else they require to function, even if sacrificing freedom, among packages provided out of Debian servers and mirrors ? I find it a bit disturbing that some (fortunately few) people who will promptly bring the priority for users into a debate to justify the packaging and distribution of non-Free Software will just as promptly forget this priority when it would amount to a minor burden for package maintainers. Admittedly, dealing with kernel modules as separate packages is far more involved than any other package split, which might require some long-term efforts to accomplish cleanly (or not, I'm not on par with how Debian deals with this). Meanwhile, I don't see any plausible reason to override the SC-stated priorities with some minor developers' convenience. There's a trivial solution for the mean time: have say two separate kernel builds, one for main, that wouldn't burden users with non-functional drivers, and one for contrib, that, when manually installed, would name the additional packages that might be necessary for portions of the package to work, at which point the user would be prompted to make informed decisions. > It is not artificial; our kernel package follows the same aggregation > as upstream (ftp.kernel.org). Not quite. Debian splits out kernel documentation, kernel headers and kernel image+modules into 3 separate packages, just to name the ones that jumped at me last time I looked into this. Splitting out some modules isn't quite as trivial, but it's not like it couldn't be done, when abiding by the two priorities stated in the SC depends on it. > the bundling is certainly more convenient ... for whom? Are both priorities being well-served by this bundling? Best, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist [EMAIL PROTECTED], gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
