LCC and blobs
Goswin von Brederlow wrote:
They would have to support merging in of source-code changes for all
architectures that any member builds. They would not be called upon to
compile those architectures.
And how will you get the other members to support architectures they do not support?
And that is without mentioning the non-free ness and license issues coming up after sarge. The firmware blobs and the like.
The whole system has to be DFSG-free. Debian won't compromise on that.
I have been thinking about the blob problem for a while. I propose to
remove blobs from the driver, and store them as files in initramfs (the
kernel-internal filesystem created by the stuff in /usr/src/linux*/usr)
or initrd.img. At boot time, the drivers would look for the blobs and
load them if they are present, and fail gracefully or fall back if they
are not. This gets around some GPL issues, because rather than be
treated as code, the blobs become external files that are just sent to
the device by the driver.
Doing the above doesn't necessarily solve the problem for Debian,
because we would still not want to distribute the blobs. but it allows
the kernel to be GPL-compliant, which I don't feel it is while the blobs
live in drivers.
An alternative is to make blobs their own loadable modules, but then we
are treating them as code rather than as just a file that the kernel
sends to some device, and we get GPL issues.