[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

non-free firmware and d-i


In the discussion about firmware-in-main, one argument that has come up
consistently is the fact that d-i doesn't currently support non-free,
and that implementing this support would take a significant development
effort. AIUI, anna would need to be updated to support multiple
installation sources, and there are other things that need to be done
and tested before this can be considered.

Since the most central point of disagreement seems to be around the need
to support non-free firmware from the installation (whether by doing
that through supporting the non-free repository, or by just dropping
these firmware blobs in main, or whatnot), I'm trying to understand what
is going on. Problem is, I don't see what the issues are, since I'm not
/that/ comfortable with d-i development. Is there a detailed explanation

Also, something I've been thinking (and suggested on #debian-boot an
hour ago, but there doesn't seem to be anyone active there ATM) is that
it should technically also be possible to implement this using something
I'll call "customization disks" for the time being: a low-priority d-i
menu item (on the same level as the "start a shell" option) which, when
activated, allows the user to load additional udebs from a floppy disk,
a usb key, a CD-ROM disk, or whatever. This loading would be done using
the udpkg equivalent of "dpkg -i". Preferably, the system would expect
these udebs to be on FAT or ISO9660 filesystems (because all operating
systems support these formats; ext2, e.g., may be harder to access from
other operating systems).

Maintainers of drivers that require non-free bits could then put this in
a udeb, which users could put on a medium their to be installed system
can read, and enjoy the happiness of a working system.

Additionally, hardware manufacturers (say, HP) can supply driver CD-ROMs
with udebs on them to accompany their hardware; this way, even hardware
that is supported by free drivers but not by the kernel in stable can
still be supported by a manufacturer if they want to backport the
driver, or so. This would probably mean that the customization disks
code would need to support some optional configuration file (I doubt
many manufacturers would like having to put udebs in the root of their
driver CD-ROM, while OTOH we don't want to require users to have to
create complex disk layouts for udebs they just downloaded from
debian.org), but that shouldn't be too hard.

In other words, as we say in Dutch, we'd be killing two flies in one

Obviously we can't be expected to support third-party udebs, but there
is no reason why we could not add a template that warns the user for
using untrusted udebs.

The question now is: is this idea feasible, and would it require
significantly less development time than extending anna to support
loading udebs from non-free, or is it all silly?

Feedback is welcome.

<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Attachment: signature.asc
Description: Digital signature

Reply to: