Ask for guidance on packaging sources with multiple libraries

[Christian Ehrhardt]

On Mon, Feb 6, 2017 at 9:40 AM, Christian Ehrhardt <
christian.ehrhardt at canonical.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.

[1] -
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
[2] -
https://lists.alioth.debian.org/pipermail/pkg-dpdk-devel/Week-of-Mon-20170206/000011.html
[3] - https://gerrit.fd.io/r/#/c/5060/

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20170207/d7791afa/attachment.html>