Joey Hess <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED]
