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
