Re: [dpdk-dev] [dpdk-techboard] Discussion on the OS Packaging of DPDK

[Ray Kinsella <mdr@ashroe.eu>]

On 10/05/2019 19:43, Thomas Monjalon wrote:
> 10/05/2019 15:43, Bruce Richardson:
>> On Fri, May 10, 2019 at 02:01:54PM +0100, Ray Kinsella wrote:
>>> ( from the undersigned )
>>>
<SNIP>
>> To a certain extent, this only applies with the "make" build system, which
>> is due to be deprecated in the next release and removed sometime next year.
>> With builds done with meson and ninja, both shared and static libraries are
>> always built. The default setting though remains as "static" which applies
>> only to the linking of applications as part of the DPDK build. This default
>> was set mainly for legacy purposes, but also has benefits for us developers
>> working on DPDK, since we don't need to worry about setting LD_LIBRARY_PATH
>> and EAL_PMD_PATH values for running applications we've built. Therefore,
>> I'm not sure of the value of changing the default here - it's certainly
>> less important than the default in the "make" build system where only one
>> library type at a time was built.
> 
> Yes no need to change the default.
> If you build DPDK yourself, it is more convenient to use static libs.
> If you want something easier to update, you probably use
> the packages from distributions which are shared libraries.

Well I disagree a bit.
I understand 100% that we don't want to break the developer experience.
My concern is that developers end using something different then, that
what the DPDK consumers are using - this always ends up being a hiding
place for bugs.

It might be worthwhile seeing if we could resolve this in another way,
either with RPATH or EAL_PMD_PATH change.

> 
>>> * Future guarantees around ABI/API stability should be provided, so that
>>> OS packagers can offer safe upgrade paths for consuming applications.
> 
> DPDK is a set of libraries, some more stable than others.
> If we cannot guarantee a full stability for a long time,
> we may have some changes here and there sometimes.
> And it's even worst with experimental functions.
> I think it is more realistic to provide a level of stability
> per DPDK library. In order to leverage such fine grained stability,
> the libraries should be packaged separately in the OS.
> Then the applications relying only on stable libraries will be able
> to link with updated libraries without any change or re-compilation.
> 
> 
>