From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: [PATCH] linux-libc-headers: Add big warning about antisocial behaviour
Date: Fri, 13 Sep 2013 12:18:14 +0100 [thread overview]
Message-ID: <1379071094.3484.245.camel@ted> (raw)
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@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
+# recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
+# makes total sense.
+#
+# -- RP
+
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
python __anonymous () {
next reply other threads:[~2013-09-13 11:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-13 11:18 Richard Purdie [this message]
2013-09-14 4:24 ` [PATCH] linux-libc-headers: Add big warning about antisocial behaviour Khem Raj
2013-09-14 7:19 ` Phil Blundell
2013-09-16 16:24 ` Khem Raj
2013-09-16 20:52 ` Phil Blundell
2013-09-16 21:27 ` Khem Raj
2013-09-16 10:08 ` Anders Darander
2013-09-16 10:05 ` Anders Darander
2013-09-16 12:37 ` Bruce Ashfield
2013-09-16 15:47 ` Mark Hatle
2013-09-16 16:06 ` Hans Beckérus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1379071094.3484.245.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.