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
