Re: [dpdk-dev] libdpdk upstream changes for ecosystem best practices

[Robie Basak <robie.basak@ubuntu.com>]

Hi Thomas,

On Wed, Sep 02, 2015 at 04:18:33PM +0200, Thomas Monjalon wrote:
> > First, it would be easier for us to ship a single binary package that
> > ships a single shared library to cover all of DPDK that library
> > consumers might need, rather than having it split up as you do. I
> > understand the build system is capable of doing this already, but what
> > we don’t have is a well defined soname and sover (currently
> > parameterized in the build) for ABI compatibility purposes. As a binary
> 
> No it is now fixed:
> 	http://dpdk.org/browse/dpdk/commit/?id=c3ce2ad3548

It's great that the name "dpdk" is pinned down - thanks. But we need to
define the sover also, and make sure it is bumped when the ABI changes.
AIUI the build currently produces no sover - is this correct?

We'll use a sover of 0 in our packaging for now, unless you object. Then
we'll be able to move up to whatever you do when it is well-defined.

> > So that we can get DPDK packaging into Ubuntu immediately, please could
> > we agree to define (and burn) libdpdk.so.0 to be the ABI that builds
> > with upstream release 2.0.0 when built with the native-linuxapp-gcc
> > template options plus the following changes:
> >     CONFIG_RTE_MACHINE=”default”
> >     CONFIG_RTE_APP_TEST=n
> >     CONFIG_LIBRTE_VHOST=y
> >     CONFIG_RTE_EAL_IGB_UIO=n
> >     CONFIG_RTE_LIBRTE_KNI=n
> >     CONFIG_RTE_BUILD_COMBINE_LIBS=y
> >     CONFIG_RTE_BUILD_SHARED_LIB=y
> 
> I feel this configuration is the responsibility of the distribution.
> What do you expect to have in the source project?

I just wanted to make it clear what we were doing in case changing build
configuration parameters resulted in a different ABI. If this isn't the
case, then that's fine - it is solely the consider of the distribution
as to what build parameters we pick.

> > The combined library would be placed into /usr/lib/$(ARCH)-linux-gnu/
> > where it can be found without modification to the library search path.
> > We want to ship it like this in Ubuntu anyway, but I’d prefer upstream
> > to have defined it as such since then we’ll have a proper definition of
> > the ABI that can be shared across distributions and other consumers any
> > time ABI compatibility is expected.
> 
> You mean you target ABI compatibility between Linux distributons?
> But other libraries could have different versions so you would be lucky
> to have a binary application finding the same dependencies.

In theory we do get ABI compatibility between distributions. Finding the
dependencies is a separate issue; but if the right binaries were
installed, there would be no conflicts in finding shared libraries
across binaries from different distributions if the ABI is managed
right.

But that isn't directly our target.

It's still useful to us to have this done right. It makes ABI
transitions in the distribution (coordinating updates to libraries and
their consumers concurrently) possible without breaking things in the
middle. It means that when we talk to upstreams (both libraries and
their consumers) then we're speaking the same language as other
distributions, and patches apply to them all without each distribution
having to kludge things independently. And it gives us options when
different library consumers require different ABI versions since we can
concurrently install two different ABIs of the same library (although we
prefer to avoid that).

> > Though not strictly part of a shared library ABI, I also propose some
> > build-related upstream changes at API level below, that I’d like to also
> > ship in the initial Ubuntu packaging of the header files. Clearly you
> > cannot make this change in an existing release, but I propose that you
> > do this for your next release so all library consumers will see a
> > consistent and standard API interface. If you agree to this, then I’d
> > also like to ship the Ubuntu package with patches to do the same thing
> > in your current release.
> 
> Yes cleanup patches are welcome :)

I'm arranging to have someone work on these with you upstream and send
you patches, thanks.

Robie