I'm writing documentation for touchpad hackers at linuxtouchpad.org and I'm trying to explain which debian package has the build dependencies for libinput (i.e. is it sudo apt build-dep libinput or sudo apt build-dep libinput10?)

Why do we even have a libinput10? I see evidence of an old libinput5 deb package in jessie debian release. Why did libinputX get a version bump when other libinput packages (such as libinput-bin and libinput-dev) did not?

The latest version of the libinput source library itself is 1.19.2 which doesn't seem relevant to the "5" or the "10" suffix.

1 Answer 1


The packaging tool used by Debian (dpkg) doesn't support installing multiple versions of the same package at the same time. So to install multiple versions of the same software, each version must be in a package with a different name.

It must be possible to install multiple versions of the same shared library, because different programs using that library are built against different versions of that library. Even if, at a given point in time, all programs using libinput are built against version 10, that won't be true forever. When version 11 comes out, it must be possible to install it alongside version 10, because not all programs using the library will be rebuilt instantly.

This constraint doesn't apply to most packages that aren't shared libraries. There's no reason to have different versions of /lib/udev/libinput* installed the same time, so there's no need to have multiple versions of libinput-bin installed. You only need to have multiple versions of libinput-dev installed at the same time if you want to build binaries of a program for multiple versions of libinput, and that's not something Debian tries to support through its packaging.

Since the library package needs to change whenever the library changes in an incompatible way, Debian defines the convention for library package names to be the name of the library followed by a number that changes whenever the library changes in such a way that old binaries can't use the new library. In other words, the library package version number must change whenever the ABI changes.

Depending on upstream's version numbering convention, ABI changes may or may not correspond to a pattern in the library's version number. There's a very widespread (but not universal) convention that the major version number changes when the API changes in an incompatible way, and an API change almost always implies an ABI change, but many ABI changes don't involve incompatible API changes. It's even possible for the ABI to change without any change in the library, if it's due to changes in another library.

The library file itself includes a name that changes when the library changes in an incompatible way: the soname. This unique name is how the dynamic loader selects the correct version. Although it isn't mandatory, most libraries use a soname of the form libfoo.so.N where N is an integer that changes each time the ABI changes in an incompatible way. Libinput on Debian follows this convention and the current value of N is 10.

$ readelf -d /usr/lib/x86_64-linux-gnu/libinput.so.10.13.0 | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [libinput.so.10]

The .10 part changes when the ABI changes in an incompatible way. The .13.0 part changes when the ABI changes in a backward-compatible way.

For more information, see:

  • Thank you so much for taking the time to write this! I thought there was more here than meets the eye, and you've tipped me towards exactly the context around these conventions that I was hoping for.
    – Duane J
    Commented Dec 3, 2021 at 19:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .