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@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@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > Archive: [🔎] 20100329215154.GA30406@gaara.hadrons.org">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/.
Attachment:
pgp9AZ3awRrmW.pgp
Description: PGP signature