The original reason for having a shared library was for the benefit of Kudzu:

Bug 212246

However, Kudzu doesn't really need a shared library, it needs -fPIC objects. We can build -fPIC objects and either put them in libpci.a or create a secondary libpci_pic.a library.

I'm anxious to get rid of the because upstream doesn't support a shared library model, and has no committment to ABI stability. Thus, any new release is liable to cause us to rev the soname with all the associated pain. Since upstream doesn't do shared libraries, binaries compiled on Debian which link against are highly unlikely to be transportable to other distros, and vice versa.

I'm open to suggestions about how to kill, but I want it dead.

Unfortunately, the pciutils package did not conform to Policy 8.1, so we have a bumpy transition ahead of us. Upgrading pciutils to 2.2.1-1 will cause anything linked against to simply stop working. Even worse, if we continued to provide a, we suspect the soname would have to rev as some structures have changed size.

I suspect we need to take the pciutils 2.1.11-15.3 sources and rename them as libpci2. The build for that would only produce the .so (and associated files). Then we upload 2.2.1-1 which doesn't build a .so, but depends on libpci2. All packages which depend on pciutils will thus depend on libpci2, and won't break. When they recompile (at their leisure), they'll find they need to link against libpci_pic if they're a library, or they'll magically statically link again if they don't need a relocatable object.

Affected Packages

Packages linking libpci into a static binary can simply be recompiled





Nicolas Boullis nboullis(%)


Bdale Garbee bdale(%)

Linked into a static binary


Noèl Köthe noel(%)


Steffen Joeris steffen.joeris(%)


Roberto Lumbreras rover(%)


Roberto C. Sanchez roberto(%)


Matthew Garrett mjg59(%)

Linked into a static binary


Ricardo Markiewicz rmarkie(%)

Linked into a plugin .so