Re: [PATCH] linux-libc-headers: exclude drm headers from sysroot

[Paul Gortmaker <paul.gortmaker@windriver.com>]

On 2015-08-04 10:52 AM, Richard Purdie wrote:
> On Tue, 2015-08-04 at 09:58 -0400, Paul Gortmaker wrote:
>> While diagnosing a problem with xf86-video-intel I noticed we had two
>> copies of drm headers in the sysroot; one from here and one from
>> the libdrm package.   The xf86-video-intel turned out to be another
>> thing, but that doesn't mean we want two copies in the sysroot with
>> different content and luck of include path indicating which one we
>> get.
>>
>> This one landed in usr/include/drm and the libdrm one put its files
>> at usr/include/libdrm, so there was no obvious over-write conflict.
>>
>> The obvious risk here would be unearthing implicit dependencies on
>> the libdrm; things trying to build before it has populated the sysroot
>> but two full highly parallel builds containing a full desktop graphics
>> suite did not show any issues.
>>
>> Cc: Bruce Ashfield <bruce.ashfield@windriver.com>
>> Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> 
> Is this something which should get addressed in the upstream kernel?

I don't think so ; my (fun!) investigation into libdrm and the commits
there seem to indicate they tend to treat the kernel as the master
repository for header content and fold changes from the uapi dir in
the kernel back into libdrm content/repository.

That said, since we (yocto) advocate people to not get all twitchy about
having the latest and greatest kernel headers, for wider compatibility,
it seemed most sensible to clobber the kernel ones and ensure the ones
we used matched the functionality of the libdrm that we are building and
actually installing.

Maybe there are arguments for going the other way, but say if we were
using the 3.19 headers still, then we'd definitely be out of sync with
the libdrm binaries we generate and deploy.

Paul.
--

> 
> I agree we likely don't want two sets of those.
> 
> Cheers,
> 
> Richard
> 
>