Hi, 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 somewhere? 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 blow. 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