[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: non-free firmware: driver in main or contrib?

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

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

- Josh Triplett

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: