Re: can a kernel in main depend on firmware in non-free to work?
On 28 Oct, 2008, Josselin Mouette <joss@debian.org> 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 oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Reply to: