Re: /usr/include/libnl3 or /usr/include

[Adrian Bunk <bunk@stusta.de>]

On Mon, Mar 04, 2019 at 11:50:43AM -0500, Jean-Francois Dagenais wrote:
> Hi guys,
> 
> There's been a couple of time when I've hit snags where packages use their version numbers in the paths of stuff they provide. This poses a small challenge where dependent recipes might have to specifically account for this "special" path.
> 
> For example, libnl is using /usr/include/libnl3 and wpa_supplicant has to specifically "hack" its configure process to be able to find the libnl headers.
> 
> Since libnl does explicitly that it cannot co-exist with it's previous versions:
> RREPLACES_${PN} = "libnl2"
> RCONFLICTS_${PN} = "libnl2"
> 
> what is the point of the sub-path?

It's where upstream installs their headers.

> Would you receive a patchset which moves libnl's headers files back at /usr/include (or rather: ${includedir}) ?
> 
> I suspect this would also set a precedent.

Diverging libnl from upstream does not sound good to me.

The correct fix would be for wpa_supplicant to use
"pkg-config --cflags libnl-3.0", and the upstream
sources are already doing that.

If this is not working without the hack in wpa_supplicant then it should 
be fixed there, but it is also possible that this hack is just a leftover
from ancient wpa_supplicant versions and can simply be removed.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed