Supporting hardware device drivers

Today was a long, long day; due to some security issues with pcsc-lite, ccid and opensc, I had to kink out a few more issues with pcsc-lite, not only because I had to workaround upstream’s decisions that focused on fixing the issues with binary distributions (read: Debian), but also because the previous stable was 1.6.1, and the micro release after that (1.6.2) broke API enough to require patching a few reverse dependencies to work out properly.

Unfortunately, of the two class of issues, the one that might sound nastier (API break on minor bump) is actually the simplest to deal with, as you just need to compile the packages against latest to make sure it builds; while on the other hand, to test the udev changes, you have to check whether the reader is detected at all. This goes further, as there are a few possible problems when mixing different libusb versions between the driver and the actual pcsc-lite handler.

Unfortunately, while a theoretical inspection tells me that some of them should work, and a few of them won’t really work anytime soon, I’m pretty much out of options. Even for packages that Ludovic maintains himself, the sync between releases leaves a lot to be desired; for others such as the Athena drivers, there is really no way to tell whether they work at all or not.

The main issue here is that a lot of those drivers, like most other packages that deal with hardware devices, is that they are usually added by a developer who had use for them, mainly by having the device at hand, but then over time, either the device was obsoleted, or the developer left, and the package has been “maintained” by people who pretend to care enough to bump it around, but never even test or check what it installs.

The main point here is that for hardware-specific packages, we should really have a way to contact who can actually tell us if it works or not; the obvious way to solve this is by ensuring that some developer has access to the hardware (I do have CCID readers, and I’ve contacted Athena today to see if they can give me the means to test their drivers on Gentoo and keep them up to date), but that’s not always possible; either because not all of us will have eternal interest on the devices, or because the use of such device requires an infrastructure they just can’t afford to deal with.

So what’s my suggestion to solve this problem in a more manageable way? Well, actually an obvious one: proxy mantainership, at a slightly different degree than usual. Usually you have a proxied maintainer sending the committer, who vouches for the general quality of the ebuild and support files, but doesn’t go much into the details of working out how the software works or how to build it. When you actually need the device, though, you mightw ant to have a co-maintainer that can actually tell you whether it works and that can debug and kink out mistakes for you, even if you are doing the whole ebuild work; this basically means that it’s the kind of proxy maintainer that doesn’t need to know the first thing about ebuilds at all, beside being able to install it with the right options.

So if you own a device, and you know that its software is in Gentoo but is not currently actively maintained, please find a developer you’re acquainted with, and become the proxy maintainer, so that the package will actually work for everyone else!