[Pkg-dpdk-devel] not-so-multiarch

Christian Ehrhardt christian.ehrhardt at canonical.com
Tue Jul 4 05:01:51 UTC 2017


Hi,
Luca and I were discussing working on a change to make the headers really
as multiarch as they should be.
Yet it turns out things are not always so easy.

If a dpdk consuming project has uses pkg-config all the time it is likely
good.
But if not there are multiple hurdles:
1. it must implement pkg-config for dpdk to get the new options for
libs/cflags
2. it must work with the new path setup

Openvswitch-dpdk is one example that has no pkg-config at the moment.
We tried to modify the config [1] but so far had no full success [2] so far.
Note: I guess the extra -include is wrong in
"-I-include /usr/include/x86_64-linux-gnu/dpdk/rte_config.h
-I/usr/include/dpdk -I/usr/include/x86_64-linux-gnu/dpdk"

But while working on it it got me thinking if that is the right approach at
all.
There might be a random number of projects out there depending on the paths
just as upstream DPDK creates them and those are unfortunately not
"/usr/include/ARCH".
We discussed and agreed that it would be a shame, to make all of the
headers non multiarch, but I had another idea.

How about splitting "libdpdk-dev" into a
- libdpdk-dev-generic
- libdpdk-dev

This could of course also be
- libdpdk-dev
- libdpdk-dev-arch
if preferred.

In any case one of them would be arch specific just holding the critical
files.
The other would stay out real multiarch package with most of the files.
That way depending projects can work as-is and we get a proper multiarch
-dev package.

Opinions?

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-dpdk-devel/attachments/20170704/279c2455/attachment.html>


More information about the Pkg-dpdk-devel mailing list