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
de...@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.
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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100329215154.ga30...@gaara.hadrons.org
