Matthew Garrett wrote: > Josh Triplett <josh.trip@verizon.net> wrote: > >>Matthew Garrett wrote: >> >>>We could do that, but it couldn't reasonably form part of the standard >>>debian-installer. A forked d-i doesn't do anyone any favours. >> >>I don't see why we couldn't put support for using contrib udebs for >>things such as drivers in the standard d-i. The contrib udebs would >>need to be in the contrib archive, and they obviously couldn't go on the >>standard CD, but they could be downloaded if needed (again, only if the >>user assents to their use), or installed from a secondary CD or one of >>the various other media that d-i can read from. > > That would require certain parts of d-i (and hence certain parts of > main) to rely upon the contents of contrib. We can't do that. I don't see how adding support for handling contrib udebs would actually create a dependency; it just makes it possible to install them if desired. This seems similar to the idea that apt supports loading packages from main, contrib, and non-free; it doesn't rely on any particular package in any of them. The sum total of the necessary support would be: 1) support to load udebs from main, contrib, or even non-free, with prompts for anything other than main, and either 2a) a generic prompt to say "should I load udebs from contrib", in which case it loads the packages before probing devices, or 2b) a mapping from detected devices to drivers and from drivers to packages, whether in contrib or main. (Much of this already exists.) None of that seems like it actually depends on anything in contrib. For comparison, base-config used to ask users if they wanted to use contrib and/or non-free packages; it was not necessarily a good idea to do this, but I don't think it created a dependency from main to contrib/non-free. As long as we are going to include support for contrib and non-free packages, it seems consistent to offer the option of using them in the installer. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature