[Pkg-dpdk-devel] ABI Bump causes symbols collision in lib consumers
Christian Ehrhardt
christian.ehrhardt at canonical.com
Tue Feb 7 09:43:20 UTC 2017
On Mon, Feb 6, 2017 at 10:06 AM, Christian Ehrhardt <
christian.ehrhardt at canonical.com> wrote:
> FYI - a discussion to the ABI bump issues I face.
> I wanted to avoid a full cross-list post - so here a link to check out the
> backgrounds.
>
> https://lists.ubuntu.com/archives/ubuntu-devel/2017-February/039659.html
>
>
There was no feedback to my call yet, but we need a solution - so here my
thoughts.
I first thought on completing the compat packages, but this time right, like
adding a symlink in d/rules for the pkg and do:
+ Package: libethdev4
+ Multi-Arch: same
+ Architecture: amd64 arm64 i386 ppc64el
+ Pre-Depends: ${misc:Pre-Depends}
+ Depends: librte-ethdev5, ${misc:Depends}, ${shlibs:Depends}
+ Section: oldlibs
+ Conflicts: libdpdk0
+ Description: Data Plane Development Kit (libethdev runtime library)
+ This is the old libethdev4 ABI provided by the backward
compatibility
+ of librte-ethdev5.
But that seemed very noisy in d/control and will grow a lot so I was
looking for "prior art" to do in a way that already is established.
I found libcurl
/usr/lib/x86_64-linux-gnu/libcurl.so.3 -> libcurl.so.4
/usr/lib/x86_64-linux-gnu/libcurl.so.4 -> libcurl.so.4.4.0
And
libhwloc.so.0 -> libhwloc.so.5
libhwloc.so.1 -> libhwloc.so.5
libhwloc.so.2 -> libhwloc.so.5
libhwloc.so.4 -> libhwloc.so.5
And
libOSMesa.so.6 -> libOSMesa.so.8
Following these the change for us would be (the same symlink) plus an
additional provides/replaces/conflicts.
Some only have the provides, but I feel all three are more correct
Package: librte-ethdev5
Architecture: amd64 arm64 i386 ppc64el
Multi-Arch: same
+ Provides: libethdev4
+ Replaces: libethdev4
+ Conflicts: libethdev4
Homepage: http://dpdk.org/doc/api/rte__ethdev_8h.html
Pre-Depends: ${misc:Pre-Depends}
Depends: ${misc:Depends}, ${shlibs:Depends}
Conflicts: libdpdk0
Description: Data Plane Development Kit (libethdev runtime library)
DPDK is a set of libraries for fast packet processing. Applications
run
in user-space and communicate directly with dedicated network
interfaces.
.
This package contains the runtime libraries for libethdev.
It is not fully equivalent as in the curl case they still stick to the old
libcurl3 names despite providing newer versions as well. Yet I think this
can be a template to base on.
Especially libhwloc seems close to our case.
Reading through [1] and [2] makes details a bit blurred.
I think we surely need the conflicts and maybe the replaces.
I'm not so sure due to the middle paragraph in [2] if there is a versioned
dependency if this will do the trick.
It might be the case that this only works if the old had a non versioned
provides that we are now moving forward and the non versioned dependencies
would fix that.
Yet clearly worth to be tested - even if breaking I'd hope it is much
closer to a real solution.
Also libhwloc has a nice dh_link override to make that in a nice and
maintainable way for all arches.
Need to see if we can borrow that as well.
If we do so we (might) get rid of the current issue, but we will have to:
- track any time we drop symbols to remove the respective old provides
- If bumping an ABI testing and adding a matching provides
I'll create commits and test them, once they are good (and no other
feedback convinces me of a better way) they will hit the review queue.
[1] -
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
[2] -
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-dpdk-devel/attachments/20170207/efdb7f0d/attachment.html>
More information about the Pkg-dpdk-devel
mailing list