Wouter Verhelst wrote: > Your mail suggests a number of things, but I feel most of those are > redundant; it should be possible to do just a subset. My mail tries to explore all the positibities, it doesn't suggest implementing them all. However, a certian amount of redundancy is necessary to get an installer that everyone can use. > * Stop providing driver disk images, requring people to create them > themselves by copying .udeb files onto a physical floppy disk or > cdrom (Rationale: this will help people understand what's really going > on, rather than have them assume that the driver disk image is > something very special which it isn't. I know I thought so before you > just told me on IRC that they only contained udebs...) This won't be practical. They are just udebs, but they have complex interedependencies and we can't expect users to pick the right set of udebs to put on a driver floppy that both supports all the hardware they need to support and fit in its limited space. For example, the i386 cd-drivers floppy contained 19 udebs. The situation may be much simpler in some cases if the particular driver media only needs to include one or two udebs containing kernel firmware, but that's no reason to break the current driver floppies. > * In case we're installing from the network, download (using a TFTP > client) a tarball with udebs from the same TFTP server we've booted > from (which would require us to figure out somehow where we booted > from). I *think* all netboot schemes involve TFTP, or am I wrong > there? > This would sidestep having to fix libd-i and anna, although it's > obviously not a proper fix for the long term. d-i doesn't have a tftp client, adding one would bloat the image (one client for network downloads should be enough). AFAIK, there's no way to figure out where the system booted from. If there is, it's probably hardware-dependent. If you have a working linux network driver, d-i is already perfectly capable of downloading drivers, including non-free drivers, from a Debian mirror (see followups to my post), so this is a non-solution anyway. > * Document for developers not involved in d-i how they can create udebs > containing NIC firmware blobs or similar, and make it clear that > *they*, not necessarily the d-i team, will have to do this if they > want their hardware to be supported in the installer. I don't think that the d-i team is opposed to helping maintainers of non-free firmware package their stuff as udebs. We already have the necessary machinery in kernel-wedge to split up non-free non-kernel-image debs into udebs, for example. > With that, the only use case you're not supporting then is the case of a > hypothetical device which can be booted with use of the device's > firmware, but which can *not* use *any* of the relevant hardware (be it > floppy, cdrom, usb, hard disk, or network) unless at least one bit of > non-free software or whatever is loaded. There are lots of use-cases you may not be taking into account. Sometimes it's just not *practical* to use certian boot methods, even if the hardware supports them. Or you just can't afford to run around to all of the hundereds of machines you're netbooting for automated installs and stick a usb key in them for the firmware. There are many outre situations where d-i shines because it has a lot of flexability and can support many different installation approaches; when we remove some of that flexability, it does end up harming d-i. > With that, I'd think we'd be covering all cases; and while it'd still > require some work, I think it's going to be significantly less than what > you suggested in your first mail. I stand by my original estimate.. > I'd be willing to do the hard work here, if needs be. I'm glad someone's interested in working on it! -- see shy jo
Attachment:
signature.asc
Description: Digital signature