On 28 Oct, 2008, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le mardi 28 octobre 2008 à 14:12 -0200, Alexandre Oliva a écrit : >> I hope the prevalent interpretation of Debian's rules and policies >> isn't so lax as to make room for such manipulation as packaging stuff >> in main that belongs in contrib or non-free just because it happens to >> be part of the same upstream package.
> It's not manipulation, it is the obvious result of how main and contrib > are split. > For another example, poppler needs a non-free package (poppler-data) to > read PDFs written in some languages. Should we move poppler to contrib > because of these languages? No, but it would make perfect sense to move to contrib the modules/components/plugins that requires poppler-data to display/read PDFs written in those languages. Even more so if they were packaged together just for e.g. convenience of download, and building them separately would be just as simple. Kernel modules *are* plugins, and the Linux build machinery is designed to enable just this kind of convenient separate building. I understand that, from a maintenance point of view, it's not so convenient to keep modules built separately, but hey, Debian's priorities are not to keep things easy to maintain, but rather freedom and users. (And there's often much discussion whenever the long-term conflicts with the short-term in either or both priorities.) That's why packages that contain Free Software along with documentation under licenses that don't pass the DFSG end up split into separate packages. Keeping the documentation that didn't pass the DFSG wasn't deemed acceptable, neither was moving the whole package to non-free. Thus the split, in spite of the inconvenience and maintenance burden. Now, why shouldn't the same care be applied to one of the most important packages in the distro? >> In fact, I have evidence to the contrary: a number of packages that >> ship as a unit upstream are split by Debian into separate packages > I don't know of such a package, but if there are, that's fine. Just > unnecessary. The alternatives, AFAIK, would be to move the entire package to non-free, no? (Assuming disrespecting the SC is not an option.) > Because the kernel is perfectly usable without the firmwares. But how about the specific modules that require them, the ones that got this sub-thread started in the first place? It doesn't make sense to me to frame the discussion in such terms as most of Linux is useful without the component's dependencies, when what we're talking about is the component, not the whole. Consider this scenario: Here's a package containing components A, B, C and D. Assume they're available separately and also as a single unit A+B+C+D upstream. A is a very important component, it's Free, and it doesn't depend on anything outside main, so it says in main. B is Free, not quite as essential, but it still doesn't depend on anything outside main. It could be packaged together, but it is made a separate binary package nevertheless, also in main. C is non-Free, so it's split out, and released in non-free, if at all. D requires C, but D itself is Free. It would make perfect sense to split D out into a package in contrib, that explicitly depended on C, so that people who found they needed D would know they needed C as well. This would also abide by the main/contrib split policies, but no, let's keep A+D in main as a unit, just because. Is there any justification other than 'because I say so'? > Since they only extend its functionality to support more hardware, > there's absolutely no reason to split the kernel packages. There *is* reason to split the linux package, I thought that was beyond any doubt by now. Debian isn't supposed to ship non-Free Software, and Linux does include non-Free firmwares. The doubt is whether the split is going to stop at the firmwares, or also cover the modules that require the firmwares. > No, the main/contrib distinction comes precisely and uniquely from > dependencies (Depends/Recommends vs. Suggests). My reading of the policy is that this is an implementation detail of consequences of the policy, not the policy itself. > Does the kernel require the firmwares in non-free for execution? Portions of it do, for sure. Those portions are artificially packaged together with the rest of Linux. If that's an argument to put something in main rather than contrib, then there's no reason for contrib to exist, since all of main+contrib amounts to a single "package" called Debian. Sure, it's not a single .deb; one could take the exercise of putting stuff that belongs in contrib with stuff that belongs in main as far as needed to show the weakness of this interpretation, and your argument is living proof of that. So what is the point of the distinction, if it can be gamed so easily? Was is not to keep Free Software that depended on non-Free Software (thus useless for those who are aligned with the Free Software only philosophy behind Debian) clearly separate? If to defeat that goal it suffices to artificially put such useless (per the above) software together with some useful (also per the above) software, in the same package, what was the point, again? Could it be that convenience and limited interpretations of practical consequences of policies are turning against the actual policies and priorities? It unfortunately looks like it from where I stand, but it could be that I'm just still missing something. If so, please share your enlightenment. Thanks in advance, -- 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]