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

Thomas Graf tgraf at redhat.com
Wed Feb 26 14:07:44 CET 2014


On 02/04/2014 04:54 PM, Thomas Monjalon wrote:
> Packages can be built with:
> 	RPM_BUILD_NCPUS=8 rpmbuild -ta dpdk-1.5.2r2.tar.gz
>
> There are packages for runtime, static libraries and development.
> Once devel package installed, it can be used like this:
> 	make -C /usr/share/dpdk/examples/helloworld RTE_SDK=/usr/share/dpdk
>
> Signed-off-by: Thomas Monjalon <thomas.monjalon at 6wind.com>

Thanks for getting this started! Some comments below. I'll be glad to
help pushing this into Fedora.

> +Name: dpdk
> +Version: 1.5.2r1
> +Release: 1

What kind of upgrade strategy do you have in mind?

I'm raising this because Fedora and other distributions will require
a unique package name for every version of the package that is not
backwards compatible.

Typically libraries provide backwards compatible within a major release,
i.e. all 1.x.x releases would be compatible. I realize that this might
not be applicable yet but maybe 1.5.x?

Depending on the versioning schema the name would be dpdk15, dpdk16, ...
or dpdk152, dpdk153, ...

> +BuildRequires: kernel-devel, kernel-headers, doxygen

Is a python environment required as well?

> +%description
> +Dummy main package. Make only subpackages.

I would just call the main package "libdpdk152" so you don't have to
repeat the encoding versioning in all the subpackages.

> +
> +%package core-runtime

What about calling it just "libdpdk"?

> +Summary: Intel(r) Data Plane Development Kit core for runtime
> +%description core-runtime
> +Intel(r) DPDK runtime includes kernel modules, core libraries and tools.
> +testpmd application allows to test fast packet processing environments
> +on x86 platforms. For instance, it can be used to check that environment
> +can support fast path applications such as 6WINDGate, pktgen, rumptcpip, etc.
> +More libraries are available as extensions in other packages.
> +
> +%package core-static

Based on the above: "libdpdk-static"

Packages that link against dpdk statically will do:
BuildRequire: libdpdk152-static

> +%files core-runtime
> +%dir %{datadir}
> +%{datadir}/config
> +%{datadir}/tools
> +%{moddir}/*
> +%{_sbindir}/*
> +%{_bindir}/*
> +%{_libdir}/*.so

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?

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}

> +%files core-static
> +%{_libdir}/*.a
> +
> +%files core-devel
> +%{_includedir}/*
> +%{datadir}/mk
> +%{datadir}/%{target}
> +%{datadir}/examples
> +%doc %{docdir}
>

You'll also need for all packages and subpackages installing shared
libraries:

%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig





More information about the dev mailing list