From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wright Subject: Re: [PATCH 03/16] pkg: add recipe for RPM Date: Wed, 26 Feb 2014 08:19:47 -0800 Message-ID: <20140226161947.GC21996@x220.localdomain> References: <1391529271-24606-1-git-send-email-thomas.monjalon@6wind.com> <1391529271-24606-4-git-send-email-thomas.monjalon@6wind.com> <530DE720.6090804@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev-VfR2kkLFssw@public.gmane.org To: Thomas Graf Return-path: Content-Disposition: inline In-Reply-To: <530DE720.6090804-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" * Thomas Graf (tgraf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org) wrote: > 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 > > 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 Yes, thanks, I meant to mention that too. Details here: https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries