Re: can a kernel in main depend on firmware in non-free to work?

[Alexandre Oliva <lxoliva@fsfla.org>]

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  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}