Re: Further fun with ABI tracking

From: Christian Ehrhardt <christian.ehrhardt@canonical.com>
To: Jan Blunck <jblunck@infradead.org>
Cc: dev <dev@dpdk.org>,
	"cjcollier@linuxfoundation.org" <cjcollier@linuxfoundation.org>,
	ricardo.salveti@linaro.org,
	Luca Boccassi <luca.boccassi@gmail.com>
Subject: Re: Further fun with ABI tracking
Date: Wed, 22 Feb 2017 14:12:12 +0100	[thread overview]
Message-ID: <CAATJJ0Kc81-yM0-oRE=rEAfXm+kZSPzueSk9ktOqr2CnOyQ8=w@mail.gmail.com> (raw)
In-Reply-To: <CALe+Z02mv3aD4TZcuO66thMTqX4f2_53Y_bs-kTo=JaxWHFgdQ@mail.gmail.com>

On Tue, Feb 14, 2017 at 9:31 PM, Jan Blunck <jblunck@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