Re: Dealing with drivers that need firmware on the filesystem
Joey Hess <joeyh@debian.org> wrote:
> Matthew Garrett wrote:
>> In the firmware case, the choice is rather different. At present, the
>> choice is not between free firmware or non-free firmware. The choice is
>> between non-free firmware on disk or non-free firmware in ROM. Putting
>> drivers in contrib penalises the former, and as a result implicitly
>> encourages the latter.
>
> What penalisation specifically results from putting a driver in contrib?
> I can think of a few things but am not sure I've hit all the relevant
> points:
As you say, there's a couple of practical issues. There's also the fact
that putting something in contrib is something of a judgement - we're
saying that this driver needs non-free code to work, and as a result
isn't worthy of going in main. Which is a touch misleading - its
dependence on non-free code is no stronger or weaker than for many
drivers in main.
> - Contrib is no longer added to sources.list per default. Perhaps this
> should be re-re-examined.
> - Software in contrib is not currently includable in d-i.
> However, if you need non-free firmware anyway, which couldn't
> be in a d-i image in any case, you need some add-on media anyway,
> probably a driver disk, which could easily include the contrib
> firmware and driver too. Or you need a special non-free build of
> the installer, which is doable, I think.
Indeed. However, at the moment, calling it a non-free build makes it
sound like it supports drivers that contain non-free code themselves.
It'd be nice to be able to make a distinction between installers that
support drivers that need loadable firmware and installers that support
binary-only drivers.
--
Matthew Garrett | mjg59-chiark.mail.debian.project@srcf.ucam.org
Reply to: