[Soc-coordination] Proposal: Automatic selection of hardware specific packages

[Julian Andres Klode]

On Mon, Mar 29, 2010 at 11:51:54PM +0200, Guillem Jover wrote:
> Hi!
> 
> I've had this idea in my head for long, but as never found the time to
> work on it, didn't feel appropriate to throw it to the wall and expect
> someone else to implement it. Anyway, it seems to me it might be a nice
> GSoC project, and not necessarily too complex. As I've my plate already
> full, I'm not volunteering myself for mentoring, though. I'm CCing
> deity at l.d.o as they should be in the loop and Petter as he was working
> on integrating package data into discover-data at some point in the past,
> which might be interested in mentoring.
> 
> Problem
> ~~~~~~~
> 
> I've always found it annoying that it's become very difficult to hunt
> all packages that might be needed for or useful with the current
> hardware on the system, and usually you tend to miss some. It might
> be even trickier for non-technical users who might not even know they
> need specific packages for something to work.
> 
> Proposal
> ~~~~~~~~
> 
> Ideally the package manager front-ends would propose for installation to
> the user all hardware related packages for currently detected hardware
> in the system, or removal once such hardware is not present (although
> that might need to be disabled for pluggable hardware). This could
> include drivers, firmware, tools and applications [0]. There's a
> distinction between packages that are required for something to work,
> which could be handled somehow as Recommends, and packages which might
> have additional functionality if the hardware is present, which could
> be handled as Suggests.
Ubuntu developed a tool called 'jockey' for installing hardware
drivers. There is an ITP for it in Bug #436722. Jockey is in my
opinion the best place to do something like this. I CCed Martin Pitt,
the developer of jockey (and quoted the remaining parts of the email
in case he did not read the original one).

> 
> Each package would provide a list of patterns for the hardware it
> supports. Depending on their size, they could be provided in a new field
> (for example Hardware-Id), or on a new control file (but then that would
> need to get extracted from binary packages and collected into a foo-data
> package for example) or something else. Those patterns would match
> against the device IDs of cpu, pci, pnp, usb, eisa, dmi, pcmcia, acpi,
> ieee1394, etc.
> 
> For some packages this information is already known, and can be
> automatically extracted from some files (and possibly converted to the
> chosen pattern format). For example X.Org drivers have an internal
> list of patterns, not sure if those can be easily extracted, for Linux
> kernel modules one can extract those with something like:
> 
>   ,---
>   |PATH=/sbin:$PATH
>   |
>   |find -name '*.ko' | xargs modinfo -F alias | \
>   |  egrep '^(pci|pnp|eisa|pcmcia|usb|acpi|dmi|ieee1394|ssb|wmi):'
>   `---
> 
> [0] An incomplete list from when I looked into this could include:
> 
>   Drivers
>   -------
> 
>   xserver-xorg-video-*, xserver-xorg-input-*, *-source, firmware-*
> 
>   Tools
>   -----
> 
>   Graphic cards: gatos, radeontool, rovclock, atitvout, s3switch,
>     i810switch, matroxset, nvclock, nvtv, libglide3.
>   Sound cards: awesfx, ld10k1.
>   Webcams: qcam, qpcr1k, pencam.
>   CPUs: athcool, set6x86.
>   Laptops: i8kutils, fnfxd, fnfx-client, toshset, toshutils, tpb,
>     spicctrl.
>   Printers: foomatic-db-hpijs, hpijs, hplip, hpoj.
>   SCSI: scsitools, sg-utils.
> 
> Design and Implementation
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Things to decide and work on, would include:
> 
>  * The format of the patterns for each hardware type. There's
>    existing examples that could be either reused or based for
>    inspiration.
> 
>  * A tool to extract at package build time as much of the IDs as
>    possible from existing files and convert them to the normalized
>    form, if need be. (Ideally independent of any packaging helper.)
> 
>  * Consider and decide where to ship such information.
> 
>  * It might be a good idea to be able to have a global override, for
>    testing purposes, and a faster initial deployment, once a working
>    implementation is in place those could be moved to each package.
> 
>  * Decide how to make the front-ends use the information, for example
>    by creating a shared library that does the detection and matching,
>    and just returns the list of packages, or through an external
>    program (say a new hwsel, or maybe just adapting and/or extending
>    disover or any of the other hardware detectors to be easily integrated
>    with the front-ends), etc.
> 
>  * The actual integration with the front-ends.
> 
> regards,
> guillem
> 
> 
> -- 
> To UNSUBSCRIBE, email to deity-REQUEST at lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org
> Archive: http://lists.debian.org/20100329215154.GA30406@gaara.hadrons.org
> 

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20100330/b19d46cc/attachment.pgp>