Standardised Hardware Support Spec - Please Review

[Alex Jones]

On Fri, 2007-04-06 at 15:20 +0100, Matt Zimmerman wrote:
> restricted-manager is needed because of the special requirements of the
> restricted driver setup.  It ties together the X server configuration,
> kernel modules, licensing, the package system, etc.  It would be preferable
> if they didn't require such complex handling, but for now this is the best
> solution available.

Yes, it does a good job of taking care of the rough edges for now, but
these rough edges /could/ be better taken care of.

> > > Similarly, I don't see how a new set of metapackages for every supported
> > > device (even if that were possible) helps to simplify this.
> > 
> > You say that as if it isn't possible. Why?
> 
> Because of the size and rate of change of this data.  Who would collect,
> formalize and maintain it, and how?  Tens of thousands of devices are
> supported by Ubuntu.

The metapackage generation would be done by using the hardware database.
It wouldn't be much work to add a new hardware device to the database,
and then officially say "it is supported" in order to do a
number_of_devices_supported++.

> > And I suggest it helps to simplify this because currently if I want to
> > install an exotic piece of hardware that isn't supported out of the box,
> > I may have to chase down several different packages if there isn't a
> > metapackage to bring it all together for me.
> 
> The examples you've provided so far are all for common devices, where I
> think that providing support by default is a more effective option.  Do you
> have particular devices or packages in mind here?
> 
> Your proposal includes as an example a metapackage which depends on:
> 
> - The USB storage kernel driver - an 88k module included with the kernel
>   supports hundreds of different devices by default
> 
> - The HAL FDI data for your phone - 140k of similar data included in the hal
>   package covers hundreds of devices by default
> 
> - Icons from Tango - I'm not sure which ones you mean, but Tango includes
>   thousands of icons which are generally a few kilobytes each, and the
>   hardware-related ones apply mostly to a wide range of devices
> 
> I don't see the value in splitting these into separate packages; the current
> scheme works very well and is much simpler.  The package metadata and
> maintenance overhead would easily outweigh finer granularity for the end
> user.

Perhaps I am expecting more flexibility from Ubuntu than I should be. If
I want USB mass storage purged from my system, I'd currently have to
roll my own kernel packages. Yes, this is a corner case. I just thought
it would be useful to someone to support it. Can you tell I run Gentoo
on other systems? Stop laughing.

> > If all of the hardware in the world was supported in Ubuntu (even if
> > that were possible :P), by both Linux kernel modules, and by the huge
> > number of userspace services and configuration tools required (/further/
> > padding out the default System Preferences menu), then no, this wouldn't
> > be an issue. I leave it to anyone who reads this to decide if it is an
> > issue or not.
> 
> I don't think there is a tangible general problem to be solved here, and
> that the issues you raise are likely to be more easily addressed directly
> (as with gnome-pilot) rather than by new infrastructure.

How do you address the gnome-pilot issue? Uninstall it when you /don't/
have the hardware? Unfortunately, hal and udev don't support
"not-plugging" yet.

> I was primarily answering the question you asked above.  The reason this
> driver is on your system is that some users do need it, and the approach
> we've taken in Ubuntu is to support a wide range of hardware by default.
> This involves a tradeoff in disk space and (occasionally) a menu item, in
> exchange for simplicity.

I just find it a completely unintuitive pain in the butt to keep my
Ubuntu system lean. I just want to say "I only want support for this set
of hardware. Everything else, get out."

> Other distributions take different approaches to this problem.  Guadalinex,
> for example, uses a system called Hermes, which dynamically installs new
> packages when hardware is detected.  This is very much along the lines of
> your proposal, and so perhaps that project would be a good place to explore
> these ideas.

I tried to get some info on Hermes but everything I find is in
Spanish. :/