From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH 03/16] pkg: add recipe for RPM Date: Wed, 02 Apr 2014 11:53:51 +0200 Message-ID: <2489854.B9BgBzrlJE@xps13> 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" Content-Transfer-Encoding: 7Bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Thomas Graf Return-path: 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" Hello, Sorry for the long delay. 2014-02-26 14:07, Thomas Graf: > On 02/04/2014 04:54 PM, Thomas Monjalon wrote: > > +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, ... We are working on this but at the moment there is no restriction on API/ABI breakage. So I think it's too early to define such rule. > > +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? > > +%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"? 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? > > +%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? 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? > 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. > You'll also need for all packages and subpackages installing shared > libraries: > > %post -p /sbin/ldconfig > %postun -p /sbin/ldconfig OK Thanks for the review -- Thomas