Add linux-libc-headers-native, make it default dep for native
RFC PATCH 1/1 Add linux-libc-headers-native, make it default dep for native
On some host distributions the provided linux kernel headers are too old to compile utilities we need[1]. Given that we need these utilities to run things on the target the best solution is to provide linux-libc-headers-native. Rather than get things into an inconsistent state, we make linux-libc-headers-native be a default dependency.
[1]: A prime example of this would be mtd-utils-native and UBI
classes/base.bbclass +6 -0
@@ -75,6 +75,12 @@ def base_dep_prepend(d): if (bb.data.getVar('HOST_SYS', d, 1) != bb.data.getVar('BUILD_SYS', d, 1)): deps += " virtual/${TARGET_PREFIX}gcc virtual/libc " + elif bb.data.inherits_class('native', d) and \ + bb.data.getVar('PN', d, True) not in \ + ("linux-libc-headers-native", "quilt-native", + "unifdef-native", "shasum-native", + "stagemanager-native", "coreutils-native"): + deps += " linux-libc-headers-native" return deps DEPENDS_prepend="${@base_dep_prepend(d)} "
(quoted diff) +0 -0
b/recipes/linux-libc-headers/linux-libc-headers.inc index 0487e65..0b0d05a 100644
recipes/linux-libc-headers/linux-libc-headers.inc +0 -0
@@ -1,7 +1,8 @@ DESCRIPTION = "Sanitized set of 2.6 kernel headers for the C library's
use."
SECTION = "devel"
LICENSE = "GPL"
+NATIVE_INSTALL_WORKS = "1"
+BBCLASSEXTEND = "native"
RDEPENDS_${PN}-dev = "" RRECOMMENDS_${PN}-dbg = "${PN}-dev (= ${EXTENDPV})"
-
(quoted diff) +0 -0
b/recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb index b66e768..0a1159a 100644
recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb +1 -0
@@ -1,6 +1,7 @@ require linux-libc-headers.inc INHIBIT_DEFAULT_DEPS = "1" +NATIVE_INSTALL_WORKS = "0" PR = "r4" # NOTE: no need to package these headers, since the c library includes
them.
PACKAGES = ""
(quoted diff) +0 -0
b/recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb index 4893cab..6cbd8ba 100644
recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb +1 -0
@@ -1,5 +1,6 @@ require linux-libc-headers.inc +NATIVE_INSTALL_WORKS = "0" HOMEPAGE = "http://ep09.pld-linux.org/~mmazur/linux-libc-headers/" # license note from the package: # Linux-libc-headers are derived from linux kernel headers. For
license of a
Signature · 2 lines
Tom Rini Mentor Graphics Corporation
Quoted 5 lines · Tom Rini
On some host distributions the provided linux kernel headers are too old to compile utilities we need[1]. Given that we need these utilities to run things on the target the best solution is to provide linux-libc-headers-native. Rather than get things into an inconsistent state, we make linux-libc-headers-native be a default dependency.
could it be made optional so people who use distribution where this is not needed are not penalized.
Quoted 75 lines
[1]: A prime example of this would be mtd-utils-native and UBI
classes/base.bbclass +0
-0@@ -75,6 +75,12 @@ def base_dep_prepend(d):if (
bb.data.getVar('HOST_SYS', d, 1)!=bb.data.getVar('BUILD_SYS', d, 1)):
deps += " virtual/${TARGET_PREFIX}gcc virtual/libc "
+ elifbb.data.inherits_class('native', d)and \
+bb.data.getVar('PN', d, True)not in \
+ ("linux-libc-headers-native", "quilt-native",
+ "unifdef-native", "shasum-native",
+ "stagemanager-native", "coreutils-native"):
+ deps += " linux-libc-headers-native" return depsDEPENDS_prepend="${@base_dep_prepend(d)} "
recipes/linux-libc-headers/linux-libc-headers.inc +0
-0@@ -1,7 +1,8 @@DESCRIPTION = "Sanitized set of 2.6 kernel headers for the C library's use."
SECTION = "devel"
LICENSE = "GPL"recipes/linux-libc-headers/linux-libc-headers.inc +2
-0+NATIVE_INSTALL_WORKS = "1" +BBCLASSEXTEND = "native"RDEPENDS_${PN}-dev = "" RRECOMMENDS_${PN}-dbg = "${PN}-dev (= ${EXTENDPV})"
recipes/linux-libc-headers/linux-libc-headers.inc +0
-1-recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb +0
-0@@ -1,6 +1,7 @@require linux-libc-headers.inc
INHIBIT_DEFAULT_DEPS = "1"
+NATIVE_INSTALL_WORKS = "0"
PR = "r4"
# NOTE: no need to package these headers, since the c library includes them.
PACKAGES = ""recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb +0
-0@@ -1,5 +1,6 @@require linux-libc-headers.inc
+NATIVE_INSTALL_WORKS = "0"
HOMEPAGE = "http://ep09.pld-linux.org/~mmazur/linux-libc-headers/"# license note from the package: # Linux-libc-headers are derived from linux kernel headers. For license of a--
Tom Rini
Mentor Graphics Corporation_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Quoted 10 lines · Khem Raj
Quoted 5 lines · Tom Rini
On some host distributions the provided linux kernel headers are too old to compile utilities we need[1]. Given that we need these utilities to run things on the target the best solution is to provide linux-libc-headers-native. Rather than get things into an inconsistent state, we make linux-libc-headers-native be a default dependency.
could it be made optional so people who use distribution where this is not needed are not penalized.
You mean like ASSUME_PROVIDED += "linux-libc-headers-native"?
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
Quoted 9 lines · Chris Larson
Quoted 7 lines · Khem Raj
Quoted 5 lines · Tom Rini
On some host distributions the provided linux kernel headers are too old to compile utilities we need[1]. Given that we need these utilities to run things on the target the best solution is to provide linux-libc-headers-native. Rather than get things into an inconsistent state, we make linux-libc-headers-native be a default dependency.
Quoted 5 lines
Quoted 3 lines
could it be made optional so people who use distribution where this is not needed are not penalized.
You mean like
ASSUME_PROVIDED+= "linux-libc-headers-native"?
heh sure,I had that in mind but I was thinking if it was otherway around where the distros which new these headers have to specify to include them and not the ones which already have them.
Quoted 10 lines
Signature · 9 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
2010/6/7 Tom Rini <[email protected]>:
Quoted 7 lines
On some host distributions the provided linux kernel headers are too old to compile utilities we need[1]. Given that we need these utilities to run things on the target the best solution is to provide linux-libc-headers-native. Rather than get things into an inconsistent state, we make linux-libc-headers-native be a default dependency.
[1]: A prime example of this would be mtd-utils-native and UBI
I'd say this is heading in the totally wrong direction.
Target code should not depend on host headers.
And if you need the target headers, you should depend on and use linux-libc-headers.
I guess mtd-utils-native is used to make an mtd image for the target and as such I would expect it to use the target headers.
What would be the difference between linux-libc-headers and linux-libc-headers-native in the first place?
(and if there is a difference, I think a better package name would be linux-libc-headers-cross).
Btw if say mtd-utils-native needs kernel headers to access host functionality using headers for a different kernel version seems to be a no-no either.
Just my eur 0.02
Frans.
PS: which distributions/distribution versions/kernel versions do have this problem?
Ubuntu 8.04 (which has a 2.6.24 kernel) does not seem to exhibit this problem).
Quoted 9 lines · Frans Meulenbroeks
2010/6/7 Tom Rini <[email protected]>:
Quoted 7 lines
On some host distributions the provided linux kernel headers are too old to compile utilities we need[1]. Given that we need these utilities to run things on the target the best solution is to provide linux-libc-headers-native. Rather than get things into an inconsistent state, we make linux-libc-headers-native be a default dependency.
[1]: A prime example of this would be mtd-utils-native and UBI
Quoted 8 lines
I'd say this is heading in the totally wrong direction.
Target code should not depend on host headers.
And if you need the target headers, you should depend on and use linux-libc-headers.I guess mtd-utils-native is used to make an mtd image for the target and as such I would expect it to use the target headers.
no. mtd-utils-native itself is a host utility so to build it we need tools and development files for the host not the target.
Quoted 3 lines
What would be the difference between linux-libc-headers and linux-libc-headers-native in the first place?
one is for target (e.g. arm) and another one would be your build system (e.g. x86)
Quoted 2 lines
(and if there is a difference, I think a better package name would be linux-libc-headers-cross).
cross is for something which runs on host and generates code for target
Quoted 18 lines
Btw if say mtd-utils-native needs kernel headers to access host functionality using headers for a different kernel version seems to be a no-no either.
Just my eur 0.02
Frans.
PS: which distributions/distribution versions/kernel versions do have this problem?
Ubuntu 8.04 (which has a 2.6.24 kernel) does not seem to exhibit this problem)._______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Quoted 15 lines · Frans Meulenbroeks
2010/6/7 Tom Rini <[email protected]>:
Quoted 7 lines
On some host distributions the provided linux kernel headers are too old to compile utilities we need[1]. Given that we need these utilities to run things on the target the best solution is to provide linux-libc-headers-native. Rather than get things into an inconsistent state, we make linux-libc-headers-native be a default dependency.
[1]: A prime example of this would be mtd-utils-native and UBI
I'd say this is heading in the totally wrong direction.
Target code should not depend on host headers.
And if you need the target headers, you should depend on and use linux-libc-headers.
Quoted 7 lines
I guess mtd-utils-native is used to make an mtd image for the target and as such I would expect it to use the target headers.
What would be the difference between linux-libc-headers and linux-libc-headers-native in the first place?
(and if there is a difference, I think a better package name would be linux-libc-headers-cross).
As Khem said, you're thinking in the wrong direction here. Target stuff which needs the headers get the headers via linux-libc-headers. The problem is runs on the host tools that generate things for the target.
Quoted 3 lines
Btw if say mtd-utils-native needs kernel headers to access host functionality using headers for a different kernel version seems to be a no-no either.
mtd-utils is depending on OK to be exported by the kernel information to know how to make a UBI image. And again, for the target this just works.
Quoted 3 lines
PS: which distributions/distribution versions/kernel versions do have this problem?
Ubuntu 8.04 (which has a 2.6.24 kernel) does not seem to exhibit this problem).
RHEL4.
Signature · 2 lines
Tom Rini Mentor Graphics Corporation
2010/6/8 Tom Rini <[email protected]>:
Quoted 21 lines
Quoted 20 lines · Frans Meulenbroeks
2010/6/7 Tom Rini <[email protected]>:
Quoted 8 lines
On some host distributions the provided linux kernel headers are too old to compile utilities we need[1]. Given that we need these utilities to run things on the target the best solution is to provide linux-libc-headers-native. Rather than get things into an inconsistent state, we make linux-libc-headers-native be a default dependency.
[1]: A prime example of this would be mtd-utils-native and UBI
I'd say this is heading in the totally wrong direction.
Target code should not depend on host headers.
And if you need the target headers, you should depend on and use linux-libc-headers.I guess mtd-utils-native is used to make an mtd image for the target and as such I would expect it to use the target headers.
Quoted 8 lines
Quoted 4 lines
What would be the difference between linux-libc-headers and linux-libc-headers-native in the first place?
(and if there is a difference, I think a better package name would be linux-libc-headers-cross).As Khem said, you're thinking in the wrong direction here. Target stuff which needs the headers get the headers via linux-libc-headers. The problem is runs on the host tools that generate things for the target.
I understand what you are saying (I think :-) )
For me ubi stuff (and mkfs.jffs2) in mtd-utils-native are tools which generate code (in this case an image) for the target. That is why I assumed them to require target headers (but see below).
(offtopic observation: mtd-utils-native delivers also a lot of stuff that is not really interesting for native (flash-erase, nandwrite, ...)
Quoted 7 lines
Quoted 4 lines
Btw if say mtd-utils-native needs kernel headers to access host functionality using headers for a different kernel version seems to be a no-no either.
mtd-utils is depending on OK to be exported by the kernel information to know how to make a UBI image. And again, for the target this just works.
What do you mean with OK?
Actually I guess it is also unclear to me what version of linux-libc-headers you want to install and I feel if they are from a different version than the native version, the native code should *not* depend on it, as it might give rise to wrong assumptions.
And if we are only talking about a missing data structure or define or so, it might be possible to add a patch to mtd-utils-native to fix that. (can't judge that as I am lacking info on what part of linux-libc-headers would be needed).
If the stuff needed is there to miss
Quoted 7 lines
Quoted 5 lines
PS: which distributions/distribution versions/kernel versions do have this problem?
Ubuntu 8.04 (which has a 2.6.24 kernel) does not seem to exhibit this problem).RHEL4.
Ouch. That brings up another question.
RHEL4 is 2.6.9 iirc. I can imagine ubi tools and 2.6.9 do not go together too well.
Do we want to do something as drastic as linux-libc-headers-native to support a fairly outdated kernel/distro.
I have some doubts here.(btw RHEL4 is already on minimal support and is EOL feb 29, 2012).(http://www.redhat.com/security/updates/errata/)
I guess this could also be solved locally. E.g. making a RHEL4
specific recipe to install the headers, or to have copies of the
needed headers in some place and add them to the inc search path
Guess this: http://wiki.openembedded.net/index.php/OEandYourDistro#CentOS_4.4_.2F_Red_Hat_Enterprise_Linux_4
could be extended with some extra instructions.
Frans.
Quoted 10 lines
--
Tom Rini
Mentor Graphics Corporation_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Quoted 37 lines · Frans Meulenbroeks
2010/6/8 Tom Rini <[email protected]>:
Quoted 18 lines
Quoted 17 lines · Frans Meulenbroeks
2010/6/7 Tom Rini <[email protected]>:
Quoted 7 lines
On some host distributions the provided linux kernel headers are too old to compile utilities we need[1]. Given that we need these utilities to run things on the target the best solution is to provide linux-libc-headers-native. Rather than get things into an inconsistent state, we make linux-libc-headers-native be a default dependency.
[1]: A prime example of this would be mtd-utils-native and UBI
I'd say this is heading in the totally wrong direction.
Target code should not depend on host headers.
And if you need the target headers, you should depend on and use linux-libc-headers.I guess mtd-utils-native is used to make an mtd image for the target and as such I would expect it to use the target headers.
Quoted 7 lines
Quoted 4 lines
What would be the difference between linux-libc-headers and linux-libc-headers-native in the first place?
(and if there is a difference, I think a better package name would be linux-libc-headers-cross).As Khem said, you're thinking in the wrong direction here. Target stuff which needs the headers get the headers via linux-libc-headers. The problem is runs on the host tools that generate things for the target.
I understand what you are saying (I think :-) )
For me ubi stuff (and mkfs.jffs2) in mtd-utils-native are tools which generate code (in this case an image) for the target. That is why I assumed them to require target headers (but see below).(offtopic observation: mtd-utils-native delivers also a lot of stuff that is not really interesting for native (flash-erase, nandwrite, ...)
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Btw if say mtd-utils-native needs kernel headers to access host functionality using headers for a different kernel version seems to be a no-no either.
mtd-utils is depending on OK to be exported by the kernel information to know how to make a UBI image. And again, for the target this just works.
What do you mean with OK?
As in headers which are clean and allowed to be used by userspace.
Quoted 4 lines
Actually I guess it is also unclear to me what version of linux-libc-headers you want to install and I feel if they are from a different version than the native version, the native code should *not* depend on it, as it might give rise to wrong assumptions.
It is up to the distribution to pick this version, just like it is for the target.
Quoted 4 lines
And if we are only talking about a missing data structure or define or so, it might be possible to add a patch to mtd-utils-native to fix that. (can't judge that as I am lacking info on what part of linux-libc-headers would be needed).
No, it's a massive headache. We went that route first.
Quoted 7 lines
If the stuff needed is there to miss
Quoted 4 lines
Quoted 4 lines
PS: which distributions/distribution versions/kernel versions do have this problem?
Ubuntu 8.04 (which has a 2.6.24 kernel) does not seem to exhibit this problem).
Quoted 5 lines
Quoted 1 line
RHEL4.
Ouch. That brings up another question.
RHEL4 is 2.6.9 iirc. I can imagine ubi tools and 2.6.9 do not go together too well.
Nope, it works great. We aren't trying to use these UBI images on RHEL4, we're using them on target hardware that's running a kernel with UBI support.
Quoted 4 lines
Do we want to do something as drastic as linux-libc-headers-native to support a fairly outdated kernel/distro.
I have some doubts here.(btw RHEL4 is already on minimal support and is EOL feb 29, 2012).(http://www.redhat.com/security/updates/errata/)
Yes, it's not EOL for another year and a half plus which means quite a lot of people are going to be using it for another year and a half plus.
I also really don't see this as drastic. The only reason it's more
than a one-liner is that once you have this, other -native recipes that are in do_compile can get mad about header versions changing under them (or being installed at just the wrong point in a compile, and other fun races).
Quoted 5 lines
I guess this could also be solved locally. E.g. making a RHEL4
specific recipe to install the headers, or to have copies of the
needed headers in some place and add them to the inc search path
Guess this: http://wiki.openembedded.net/index.php/OEandYourDistro#CentOS_4.4_.2F_Red_Hat_Enterprise_Linux_4
could be extended with some extra instructions.
IMHO, that seems rather drastic. If we don't want to cleanly / fully support RHEL4, I can just stop posting these kind of things. It's not my favorite build host either :)
Signature · 2 lines
Tom Rini Mentor Graphics Corporation
Quoted 7 lines · Tom Rini
On some host distributions the provided linux kernel headers are too old to compile utilities we need[1]. Given that we need these utilities to run things on the target the best solution is to provide linux-libc-headers-native. Rather than get things into an inconsistent state, we make linux-libc-headers-native be a default dependency.
[1]: A prime example of this would be mtd-utils-native and UBI
ping? The summary of the feedback, I believe would be:
- Can we just make this opt-in for distros that need it?
- Can we easily opt out if we don't?
For the second, yes, ASSUME_PROVIDED still works. For the first, I'd argue that doing so is a lot harder (at least without some additional infrastructure and reliance on other external tools) than just adding another early package.
So, yay or nay?
Quoted 61 lines
classes/base.bbclass +6
-0@@ -75,6 +75,12 @@ def base_dep_prepend(d): if (bb.data.getVar('HOST_SYS', d, 1) != bb.data.getVar('BUILD_SYS', d, 1)): deps += " virtual/${TARGET_PREFIX}gcc virtual/libc " + elif bb.data.inherits_class('native', d) and \ + bb.data.getVar('PN', d, True) not in \ + ("linux-libc-headers-native", "quilt-native", + "unifdef-native", "shasum-native", + "stagemanager-native", "coreutils-native"): + deps += " linux-libc-headers-native" return deps DEPENDS_prepend="${@base_dep_prepend(d)} "recipes/linux-libc-headers/linux-libc-headers.inc +0
-0@@ -1,7 +1,8 @@ DESCRIPTION = "Sanitized set of 2.6 kernel headers for the C library'suse."
SECTION = "devel"
LICENSE = "GPL"recipes/linux-libc-headers/linux-libc-headers.inc +2
-1+NATIVE_INSTALL_WORKS = "1" +BBCLASSEXTEND = "native" RDEPENDS_${PN}-dev = "" RRECOMMENDS_${PN}-dbg = "${PN}-dev (= ${EXTENDPV})" -recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb +1
-0@@ -1,6 +1,7 @@ require linux-libc-headers.inc INHIBIT_DEFAULT_DEPS = "1" +NATIVE_INSTALL_WORKS = "0" PR = "r4" # NOTE: no need to package these headers, since the c library includesthem.
PACKAGES = ""recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb +1
-0@@ -1,5 +1,6 @@ require linux-libc-headers.inc +NATIVE_INSTALL_WORKS = "0" HOMEPAGE = "http://ep09.pld-linux.org/~mmazur/linux-libc-headers/" # license note from the package: # Linux-libc-headers are derived from linux kernel headers. Forlicense of a
Signature · 2 lines
Tom Rini Mentor Graphics Corporation
Leon Woestenberg
Acked-byHello Tom,
Quoted 7 lines · Tom Rini
For the second, yes,
ASSUME_PROVIDEDstill works. For the first, I'd argue that doing so is a lot harder (at least without some additional infrastructure and reliance on other external tools) than just adding another early package.So, yay or nay?
I would say the ASSUME_PROVIDED for the native linux headers should be mentioned in the local.conf.sample,
commented out, so that users can enable it easily (optimize the build like Khem says).
Could you add that to the patch, or as a follow-up patch?
Regards,
Signature · 1 line
Leon
Quoted 8 lines · Leon Woestenberg
Hello Tom,
Quoted 5 lines · Tom Rini
For the second, yes,
ASSUME_PROVIDEDstill works. For the first, I'd argue that doing so is a lot harder (at least without some additional infrastructure and reliance on other external tools) than just adding another early package.
Quoted 8 lines
Quoted 2 lines
So, yay or nay?
I would say the
ASSUME_PROVIDEDfor the native linux headers should be mentioned in the local.conf.sample,
commented out, so that users can enable it easily (optimize the build like Khem says).Could you add that to the patch, or as a follow-up patch?
As a follow-up:
conf/local.conf.sample +0 -0
@@ -30,6 +30,11 @@ BBFILES := "${@bb.fatal('Edit your conf/local.conf: BBFILES')}" # This is a regulary expression, so be sure to get your parenthesis
balanced.
BBMASK = ""
+# Uncomment this if your host distribution has recent enough Linux +# Kernel header files. Utilities we use to generate certain types of +# target filesystems need somewhat recent header files.
+# ASSUME_PROVIDED += "linux-libc-headers-native"
+
# Uncomment this if you want to use a prebuilt toolchain. You will need to
# provide packages for toolchain and additional libraries yourself. You also # have to set PATH in your environment to make sure BitBake finds additional binaries.
Signature · 2 lines
Tom Rini Mentor Graphics Corporation
2010/6/16 Tom Rini <[email protected]>:
Quoted 36 lines
Quoted 11 lines · Leon Woestenberg
Hello Tom,
Quoted 7 lines · Tom Rini
For the second, yes,
ASSUME_PROVIDEDstill works. For the first, I'd argue
that doing so is a lot harder (at least without some additional infrastructure and reliance on other external tools) than just adding another early package.Quoted 8 lines
Quoted 2 lines
So, yay or nay?
I would say the
ASSUME_PROVIDEDfor the native linux headers should be mentioned in the local.conf.sample,
commented out, so that users can enable it easily (optimize the build like Khem says).Could you add that to the patch, or as a follow-up patch?
As a follow-up:
conf/local.conf.sample +0
-0@@ -30,6 +30,11 @@ BBFILES := "${@bb.fatal('Edit your conf/local.conf:BBFILES')}"
# This is a regulary expression, so be sure to get your parenthesis balanced.
BBMASK = ""conf/local.conf.sample +5
-0+# Uncomment this if your host distribution has recent enough Linux +# Kernel header files. Utilities we use to generate certain types of +# target filesystems need somewhat recent header files. +# ASSUME_PROVIDED += "linux-libc-headers-native" +# Uncomment this if you want to use a prebuilt toolchain. You will need to
Quoted 8 lines
# provide packages for toolchain and additional libraries yourself. You also # have to set PATH in your environment to make sure BitBake finds additional binaries.--
Tom Rini
Mentor Graphics Corporation
Suggest to write a separate email with a catchy title telling people that this change becomes in effect (after the commit is done).
rationale: after the change is made, people will get the headers by default, and not everyone reads this thread.
Frans