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

[Neil Horman]

On Wed, Apr 02, 2014 at 11:53:51AM +0200, Thomas Monjalon wrote:
> 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.
>  
Now that you have DSO builds in place, theres no reason not to take the extra
step of versioning your API's, making backwards compatibility fairly
straightforward.  Monolithic builds are still somewhat problematic regarding API
stability, but you could certainly offer stability in the DSOs.

> > > +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"?
> 
The version name should be left out of the library name, whatever you do.
Packaging can be responsible for versioning.

> 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 strictly, but IIRC if you don't add the lib, the linker won't find it with
the -l option, so you'll want to add it.

> > > +%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?
> 
If the versioning is done properly (i.e shared libraries get version ids
attached to the library files properly), you can install as many library
versions as you like.  You can only install a single -devel package, since it
links lib<name>.so to a specific version.

> > 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
>