[OE-core] [PATCH] linux-libc-headers: Add big warning about antisocial behaviour

[Hans Beckérus]

On Mon, Sep 16, 2013 at 5:47 PM, Mark Hatle <mark.hatle at windriver.com> wrote:
> On 9/13/13 6:18 AM, Richard Purdie wrote:
>>
>> I'm getting concerned with the number of people forking this recipe
>> and not understanding what they're doing. I'm therefore proposing
>> adding in a suitable warning to people thinking of copying it.
>>
>> Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
>> ---
>> diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> index 96fe2ff..79b7dc4 100644
>> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> @@ -2,6 +2,28 @@ DESCRIPTION = "Sanitized set of kernel headers for the C
>> library's use."
>>   SECTION = "devel"
>>   LICENSE = "GPLv2"
>>
>> +#########################################################################
>> +####                        PLEASE READ
>> +#########################################################################
>> +#
>> +# You're probably looking here thinking you need to create some new copy
>> +# of linux-libc-headers since you have your own custom kernel. To put
>> +# this simply, you DO NOT.
>> +#
>> +# Why? These headers are used to build the libc. If you customise the
>> +# headers you are customising the libc and the libc becomes machine
>> +# specific. Most people do not add custom libc extensions to the kernel
>> +# and have a machine specific libc.
>> +#
>> +# But you have some kernel headers you need for some driver? That is fine
>> +# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
>> +# This will make the package using them machine specific but this is much
>> +# better than having a maching specific C library. This does mean your
>
>
> Typo in the above, "maching" should be "machine"...
>
>
>> +# recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
>> +# makes total sense.
>> +#
>> +# -- RP
>> +
>
>
> I am completely in favor of this.  People don't get that custom kernel
> headers have severe ramifications in projects.  I've had to explain this to
> hundreds over the last few years (and they keep doing it anyway)..
>
> Acked-by: Mark Hatle  (with change mentioned above)
>
> --Mark
>
I can only agree to that what you are saying makes perfectly sense. Do
not fix what is not broken ;)
However, we did stumble into one problem when stepping up to a later
baseline using a 3.8 kernel. The patch for Makefile.headerinst could
not be applied to our vendor specific 3.6 kernel branch so we were
force to disable it completely. Did we take the wrong turn somewhere?

Thanks.
Hans


>
>>   LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>>
>>   python __anonymous () {
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core