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

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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