[dpdk-dev] [PATCH 03/16] pkg: add recipe for RPM

[Thomas Graf]

On 04/02/2014 11:53 AM, Thomas Monjalon wrote:
> 2014-02-26 14:07, Thomas Graf:
>>> +BuildRequires: kernel-devel, kernel-headers, doxygen
>>
>> Is a python environment required as well?
>
> Python is only needed to run some tools on the target. But is is optional.
> Do you think it should be written somewhere?

Not sure what target is in this context. You only need to list it if
a python environment must be present at build time.

>> What about calling it just "libdpdk"?
>
> In this case, it should be libdpdk-core in order to distinguish it from dpdk
> extensions. But the name of the project is dpdk so it seems simpler to call it
> dpdk-core.
> Is the "lib" prefix mandatory for libraries?

Not at all. You are free to name the package. The mandatory part is that
runtime and development files must be separated and the development
files such as headers will go into a -devel package.

dpdk-core
dpdk-core-devel

>> This brings up the question of multiple parallel DPDK installations.
>> A specific application linking to library version X will also require
>> tools of version X, right? A second application linking against version
>> Y will require tools version Y. Right now, these could not be installed
>> in parallel. Any chance we can make the runtime version independent?
>
> Are you thinking about installing different major versions? In my
> understanding, we cannot install 2 different minor versions of a package.
> As long as there is no stable API, there is no major versions defined.
> So don't you think we should speak about it later?

That's right, you can't install multiple versions of the same package
unless you name them differently. This is why we need to come up with a
strategy how to handle naming and upgrades now, before we push it into
Fedora.

Example:
Let's assume we push DPDK 1.6.0 into Fedora as 'dpdk-core' with NVR
dpdk-core-1.6.0-1. Let's assume we later push Open vSwitch 2.2 into
Fedora which will consume DPDK 1.6.0 via "Requires: dpdk-core = 1.6.0"
We can't do dpdk-core >= 1.6.0 because there is no compatibility.
DPDK 1.6.1 gets released and we push it as dpdk-core-1.6.1-1. We then
push dpdk-pktgen into Fedora which is based on DPDK 1.6.1 and requires
"dpdk-core = 1.6.1". Users won't be able to install both OVS and
dpdk-ptkgen in parallel at this point because they can't install both
1.6.0 and 1.6.1.

Fedora inclusion will require a strategy to resolve this. A unique name
for each release is an option (Every DPDK release is currently a new
major release). This can slowly transform into compatible releases once
stable ABIs are in place.

Unique names is not enough though as multiple packages would still
attempt to install the same file, e.g. header files. This would be
typically resolved by installing headers and other non versioned files
with a prefix as outlined below. This leaves the problems of tool
versioning as they also seem to be bound to specific DPDK versions but
can't be prefixed as they need to be part of $PATH.

So while we don't have to enforce stable ABIs at this point we have to
account for the lack of it in the packaging names and packaging
structure.

Packages could be named

dpdk-1.6.0-core
dpdk-1.6.0-core-devel
....

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming


>> Same applies to header files. A good option here would be to install
>> them to /usr/include/libdpdk{version}/ and have a dpdk-1.5.2.pc which
>> provides Cflags: -I${includedir}/libdpdk${version}
>
> Yes same applies :)
> I agree that a .pc file would be a good idea. But we also must allow to build
> with the DPDK framework.

Definitely.