Nathanael Nerode <[EMAIL PROTECTED]> writes: > Joe Smith wrote: > >> "Sven Luther" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> 1. Module and firmware in free. (The firmware can be compiled into the >> module, or can be loaded from a file.) >> >> 2. Module in free, firmware in nonfree, loaded from file by driver. [One >> could argue that the modules belong ion contrib, unless the firmware is >> optional (perhaps allowing access to non-essential features)]. >> >> 3. Module in non-free. [Firmware compiled into module, has not yet be >> seperated into seperate file. This is acceptable, but many of these could >> be converted to type 2 if somebody puts in the work]. >> >> >> I know we have some modules of type 1. I'm pretty sure we have some >> modules of type 3. It has not been clear to me if we currently have any >> modules of type 2. > > Yes, we do. bluez-firmware and atmel-firmware. > >> Obviously if the infrastucture is not there, that should be fixed. > > It's there except for d-i.
Actualy D-I has the support it needs for this, at least net-retriever I checked myself. But if the cd-retriever lacks it then it is trivial to add the same code there. What isn't there is the md5sum / sha1 sum in the release file for non-free/debian-installer/* on the debian archive. A minor config problem. The only real problem left arises when you need firmware to access the udebs containing the firmware. That means if you use netboot and need firmware for the network card or netinst and a cdrom that needs firmware to be accessible. That can only be solved by building non-free D-I images that already include non-free firmware. I don't think that needs anything but config file changes for the build process. Besides D-I there is also the problem of debian-cd. Someone has to build non-free CD images that include the firmware udebs. That is mainly a infrastructure matter and not a software problem though. >> Then we have DI. AIUI D-I curretly lacks support for Type 2 and Type 3 >> modules. This can definately be fixed, but doing it for etch could delay >> release. > > Right. Wrong, see above. Surprisingly enough the support for this was addes _5_ years ago to support having udebs in main and local sections. A non-free section is just a variation of that. >> So the question I have is how long would etch need to be delayed to add >> support for non-free firmware to D-I? > > Joey Hess estimated 6 months work, but that was to implement a whole bunch > of uncommon special cases. I think it is totally unnecessary to implement > all, or even any, of those. > > http://lists.debian.org/debian-vote/2006/08/msg00122.html (1) was nearly done. The Release file are missing the checksums. Minor problem. > For (2) from that post, which is the key sticking point for d-i, it needs to > be done anyway, and honestly should not take more than a month if someone > bothers. > > So -- point me to the correct parts of the installer. I don't know where to > find this "anna". libdebian-installer I'm looking at -- it would be a great > help if someone could direct me to the part of the code which loads udebs > from disk/network, because I can't find it. Is that all in 'anna', which I > can't find? :-/ If I can't find the source code for 'anna', I can't fix > it. (2) was done 5 years ago (for the non-free case) by having the retriver concatenate the downloaded Packages files into one before passing it off to anna/libd-i. That way the problem is circumvented. I also have a patch for libd-i to parse multiple packages files but Bastian told me that the internal data structures of the parser will break if packages with the same name appear and dependency resolving might be off. Something I haven't yet seen happening since all my tests had disjunct Packages files. This feature would only be needed to support 3rd party repositories inside the installer though. Not for Debians non-free. One could also extend the trick of concatenating the packages file even for 3rd party repositories. The retriever just need an extra option to no delete the old file. > (3) is trivial and simply requires the will to fix RC bugs. (3) is wrong since there is a frimware-nonfree package with 2 firmware udebs in experimental for example. > > (4) is frankly not nearly as important as Joey makes it out to be. It is > very unlikely that someone will have a machine where *both* the CD *and* > the NIC *and* the floppy drive if present *and* the USB driver (USB key) > need non-free firmware. > > As long as there is one piece of hardware with fully free drivers which can > be used to load the additional non-free material on the machine, it is > perfectly tolerable that an alternate piece of hardware is not so > supported. (I've seen systems where the NIC needed non-free firmware > downloaded and ones where the CD did, but never ones where both did.) I > know it's theoretically possible that someone will buy a "hell machine" > where every single peripheral requires a non-free firmware download -- but > it's unlikely. And if that happens, they can still use the hard drive > method or master their own CD. (4) is the actual problem. But more a problem of organizing and deciding. Maybe we could compromise by making only a non-free (but comercially distributable) image and have a question "Use non-free? y/n" for those that insist on using 100% free software. If that is too much then I fear having a free and non-free image is the only solution. I would rather have non-free in the actual installer images and have it labled as such on the CD (it would be in pool/non-free) than have the non-free firmware remain in the kernel itself and on every installed system but still claim 100% free. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
