[dpdk-dev] Further fun with ABI tracking
Christian Ehrhardt
christian.ehrhardt at canonical.com
Wed Feb 22 14:12:12 CET 2017
On Tue, Feb 14, 2017 at 9:31 PM, Jan Blunck <jblunck at infradead.org> wrote:
> > 1. Downstreams to insert Major version into soname
> > Distributions could insert the DPDK major version (like 16.11) into the
> > soname and package names. A common example of this is libboost [5].
> > That would perfectly allow 16.07.<LIBABIVER> to coexist with
> > 16.11.<LIBABIVER> even if for a given library LIBABIVER did not change.
> > Yet it would mean that anything depending on the old library will have to
> > be recompiled to pick up the new code, even if it depends on an ABI that
> is
> > still present in the new release.
> > Also - not a technical reason - but it is clearly more work to force
> update
> > all dependencies and clean out old packages for every release.
>
> Actually this isn't exactly what I proposed during the summit. Just
> keep it simple and fix the ABI version of all libraries at 16.11.0.
> This is a proven approach and has been used for years with different
> libraries.
Since there was no other response I'll try to wrap up.
Yes #1 also is my preferred solution at the moment.
We tried with individual following the tracking of LIBABIVER upstream but
as outlined before we hit too many issues.
I discussed it in the deb_dpdk group which acked as well to use this as
general approach.
The other options have too obvious flaws as I listed on my initial report
and - thanks btw - you added a few more.
@Bruce - sorry I don't think dropping config options is the solution. Yet
my suggestion does not prevent you from doing so.
> You could easily do this independently of us upstream
> fixing the ABI problems.
I agree, but I'd like to suggest the mechanism I want to implement.
An ack by upstream for the Feature to set such a major ABI would be great.
Actually since it is optional and can help more people integrating DPDK
getting it accepted upstream be even better.
I'll send a patch in reply to this thread later today that implements what
I have in mind.
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
More information about the dev
mailing list