This Time Self-Hosted
dark mode light mode Search

Merging the hardware data

First off, thanks to Greg who actually pointed me to the right blog post which I referred to in my previous one: this one by Matt Domsch.

Edit 2012/03/21: changed the URL to Matt’s blog post as it was moved.

And again thanks to Greg for letting me get in touch with Matt, and we now are discussing the issue of shared hardware data.

As an experiment, I’ve added to my overlay a live GIT ebuild for hwdata, And to make use of that, I also added ebuils for a few packages to use that data rather than installing their own or using others’ data: pciutils and usbutils (which now don’t install their own data), lshw (which also installed its own data before), hal (rather than using pciutils’ and usbutils’; note that I made hwdata not install the compressed copies at all, it only installs the uncompressed ones at the moment), sysfsutils (see also bug #208651), systemsettings (KDE4, it installed its own usb.ids), and KControl (KDE 3.5, it used usbutils’ usb.ids).

I don’t know at the moment if there are more users of usb.ids and pci.ids, if there are, please tell me and I’ll prepare modified ebuilds for that too so that the experiment can be completed. Also note that all the related ebuilds have KEYWORDS="", so they are never merged in unrequested when you use my overlay, they also got -r99.

There are other kind of data we might like to have in the hwdata package, for instance the oui database, which in my system is duplicated in both Wireshark and lshw, and which can be installed by both KControl and systemsettings when enabling FireWire support.

Now, continuing this way we might actually be able to finally have everything done in one place, and shared across the plane, rathe than having multiple copies of data 🙂

Comments 2
  1. The link to Matt Domsch’s post doesn’t work for me … is there a mirror? Thanks!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.