Tuesday, 7 February 2017

Re: Ask for guidance on packaging sources with multiple libraries


On Mon, Feb 6, 2017 at 9:40 AM, Christian Ehrhardt <[email protected]com> wrote:
TL;DR:
How to correctly package a source creating libraries with individual ABI's bumped separately but that depend on each other and due to that ending up in mixed versions in the executable after ld.so mapped in dependencies?
I'm reaching out to you as this is a case I have no experience with.
I've thought and discussed on several solutions but I'm sure on none of them yet.
  • Compat packages with symlinks to the new .so version as it has ABI backward compat symbols
  • Hard inserting the major version (currently 16.11) into every library version e.g. making the new a librte_eal.so.16.11.3
  • Some magic combination of breaks/conflicts/replaces that prevents the error window (lib updated, but not consumers) to occur
  • Others according to your guidance

I analyzing the compat package approach of above (see the original mail about some details on the DPDK ABI compat model).
That seemed to be the approach being the lowest hanging fruit (a.k.a not revamping big chunks of upstream code).

To get more ideas how to package that I was checking the archive for other packages with similar cases.
I found several like libcurl, libhwloc and libOSMesa to have symlinks from older sonames.
Of those libhwloc appeared to be most similar to our case:
  libhwloc.so.0 -> libhwloc.so.5
  libhwloc.so.1 -> libhwloc.so.5
  libhwloc.so.2 -> libhwloc.so.5
  libhwloc.so.4 -> libhwloc.so.5

I was studying the packaging of all those and found that in their cases the dependencies where non versioned.
Therefore those packages implemented this compat with symlinks to the new soname and as "provides" field for the old named package.

But according to [1] "... If a relationship field has a version number attached, only real packages will be considered to see whether the relationship is satisfied ... "
Thereby for our case this will likely not work - I confirmed that in an experimental build.

From there the next step was to create explicit (and versioned) packages to hold the symlink to the ABI compatible new version.
I implemented that and it works great for all combinations of old/new library and library-consumers, see [2] (this thread also holds more on why just provides fields fail).
The change itself is out for review [3] and discussion on deb_dpdk.

So I have a solution that works, but wanted to hereby post it to ubuntu-devel before I upload to get an early nack if it has an hidden fault.


--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd