Improving .deb

Posted May 30, 2019 15:50 UTC (Thu) by imMute (guest, #96323)
In reply to: Improving .deb by compenguy
Parent article: Improving .deb

>Deb's tooling doesn't let you provide/require a SONAME, rather the tooling will look at known packages and use the name of the package that installs that lib as the dependency.

I wonder if this wouldn't be possible in debs with some creative use of Provides and Requires. A package containing a library that "provides" some SONAME could have a "Provides: SONAME-libfoo.so.2" on it. Packages that need that SONAME could add "Requires: SONAME-libfoo.so.2". Specific versioning would be tricky, since you can't know the exact versioning a providing package uses. I'm thinking epoch versions might throw a wrench in there... Also that the SONAME "version" number and the package version number (even just the "upstream" part) aren't always numerically the same.

Since everyone should already be using dh_makeshlibs / dh_shlibdeps, this might not even be too hard to prototype...

Improving .deb

Posted May 31, 2019 14:58 UTC (Fri) by patrakov (subscriber, #97174) [Link]

In this particular case, there is a policy how to name packages providing shared libraries, and a lintian check that enforces it. E.g., under this policy, a package that provides libncurses.so.6 must be named libncurses6. So this is a case of convention over configuration, but the end result is the same.