On Tuesday 12 September 2006 05:59, ldoolitt@recycle.lbl.gov wrote: > > implementation of a solution for firmware/non-free drivers in d-i has > > been discussed but consensus was that there was not much point in > > working on it while there was no separation in the kernel; > > This is half-true. > > It is true that many high-profile drivers in the upstream kernel _still_ > have their firmware mingled with the (often GPL'd) driver, and their > developers show resistance to treating that as a bug. > > But it is also true that the upstream kernel has used the > request_firmware() mechanism (for a subset of its drivers) for quite a > while. As a random data point, the March 2, 2005 release of linux-2.6.11 > included about 20 drivers that used that mechanism to load their > firmware. So if the Debian project (kernel and d-i together) had > interest in supporting the separation, there were ample test-cases > available. I'm sorry, but I don't see what your comments have to do with discussion about implementation _in Debian Installer_. They are probably true for the discussion about firmware separation in the kernel, but that was not my point. > > unless both Joey Hess and I, after careful review of a finished and > > tested proposed solution, decide that 1) it provides an acceptable > > solution for all installation methods and architectures, 2) it poses > > no risk of regressions or delays in the run-up to the release." > > Do I interpret this correctly, that the existing firmware-nonfree > package will only be useful post-etch? Well, we currently don't have any support for it. So if it contains firmware that is important for our users then we will have to see how we can deal with this. The outcome of this resolution will determine what options will be open to us.
Attachment:
pgpmRSMx5aCQl.pgp
Description: PGP signature