Anthony Towns wrote:
> If it makes sense, what are the major difficulties/inconveniences/whatever
> that were found in having this happen for etch, that will need to be
> addressed to achieve an etch+1 release that's both useful and convenient
> for both people who need/want non-free things, and those who want a
> completely free system?
From the d-i side, the major difficulties are:
1. The archive did not support a non-free section for udebs until today.
2. libd-i and anna do not support multiple udeb sources, but can only
pull from one at a time; noone has yet fixed this
3. The Debian kernel does not currently have non-free firmware separated
into different packages.
4. Numerous installation cases become much more complex assuming the
above is all implemented. Examples:
a. netboot install where the NIC needs non-free firmware.
Possible solutions include:
i. Ship a non-free installation image, either extra-debian (as is
done for the nslu2), or in non-free. With the problems that:
* Such an image will automatically become the image most users use
to install, since it's more likely to work.
(Example: the nslu2 install image)
* So the free image won't be used or tested much.
* So we've doubled our work and QA for no actual benefit.
ii. Ship only a single free image, with some procedure (ie,
cat firmware.cpio >> initramfs) that users can run to make it
include the non-free firmware.
* This limits the users who can use it to users competant to
assemble it on their own.
iii. Require that the user feed the machine some media with the
firmware.
* Assumes that the drivers for the media don't need non-free
firmware.
* Assumes that the machine supports removable media.
* Removes most of the benefit of netbooting in the first place.
b. CD install where the CD, disk, NIC, etc need non-free firmware.
Possible approaches include:
i. Provide some way for the user to remaster the CD.
* Too hard for most users.
* If the CD drive itself needs non-free firmware they will
need to modify the initrd too, which gets into the really
hard territory.
ii. Allow some way for the user to add a new session to the CD
containing the non-free firmware.
* No idea how this could work, but it does prove that drunken
late night discussions at DebConf are good for something.
* Wouldn't address any firmware that needs to go in the initrd,
ie, CD driver firmware.
iii. Require additional media (floppy, usb key) or network.
* Assumes that the drivers for the that don't need non-free
firmware and that the machine supports floppy, usb or network.
iiii. Ship a separate non-free CD.
* Which then becomes the one everyone uses because it works, as
with the non-free netboot image above.
* Does bad things to our CD/DVD disk space requirements.
Also, in the case of a CD that needs non-free firmware, we have to
provide the installer with a way to get not just udebs for the
firmware, but debs for it, for the installed system. This
complicates all of the above approaches significantly.
c. CD or network, etc install where the disk drive needs non-free
firmware. If we have 1, 2, and 3 done, this isn't a large issue,
but yet another complexifying case.
d. Install _from_ hard disk (internal or USB), where the disk needs
non-free firmware.
This is probably the easiest installation media for a user to
modify to add non-free firmware, so it may be amoung the easier
cases to handle.
5. Implementing anything in 5 is a lot of work. Implementing it all
will be pretty atrocious. My guess is still 6 months of solid work to
implent a credible subset of 5, just like it has been all along.
6. We have no clear idea as to which of these possibilities is feasable
or the right way to go.
7. People seem to find it much more rewarding to work on fixing bugs in
d-i and adding spiffy new features like hard drive encryption and GUI
installers than on firmware splitting. And more power to them..
(The work done for the nslu2 provides a small counterpoint to this.)
It's worth noting that all of the above also applies to including
non-free kernel modules in the installer, although AFAIK we don't have
many if any of those in a form suitable for d-i in the archive.
--
see shy jo
Attachment:
signature.asc
Description: Digital signature