On Mon, 19 Apr 2010, Koen Kooi wrote:
On 19-04-10 16:34, Vitus Jensen wrote:
Signed-off-by: Vitus Jensen <[email protected]>
---
conf/distro/angstrom-2008.1.conf | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/conf/distro/angstrom-2008.1.conf b/conf/distro/angstrom-2008.1.conf
index 2b03e71..00f1a01 100644
--- a/conf/distro/angstrom-2008.1.conf
+++ b/conf/distro/angstrom-2008.1.conf
@@ -81,7 +81,7 @@ PREFERRED_VERSION_linux-handhelds-2.6 ?= "2.6.21-hh20"
#KERNEL_INITRAMFS_PATH = "${KERNEL_INITRAMFS_DIR}/$(readlink
${KERNEL_INITRAMFS_DIR}initramfs-bootmenu-image-${MACHINE}.cpio.gz)"
#This is unrelated to the kernel version, but userspace apps (e.g. HAL)
require a recent version to build against
-PREFERRED_VERSION_linux-libc-headers = "2.6.31"
+PREFERRED_VERSION_linux-libc-headers ?= "2.6.31"
NACK, there's is a good reason it's not soft assigned. Your hack to make
it machine specific is worse, since it means that other machines with
the same arch now get a "random" version.
Well, if they don't prefer a version and use angstrom they get .31.
llc is only the description if the interface to kernel, IMHO a program
should work with any version new enough to contain requested features. I
can think of two reasons to select a fixed version:
- either you want to use the exact same version as the kernel you are
running (for whatever reason), in this case it's a machine-specific
setting.
- or some userspace code has problems with newer headers. In this case
it's application specific and some parsing code would have to parse all
used recipes. But it would be better to fix userspace code in this case.
So floating would be fine with me. But I'm on stable/2009 so I don't care
how it's done in .dev
What we can do is globally increase the version, which was planned
anyway. Does can need .32 or .33? I tested using llc .32 locally, but
hadn't pushed that change yet.
llc .32 would be good enough.
Vitus
--
Vitus Jensen, Hannover, Germany, Universe (current)
pgp public key available from keyservers
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
