Ben Hutchings wrote:
> I think the problem is that many generic scripts that attempt to
> capture the kernel version will not use 'uname -a', 'uname -rv', or
> similar. If they were to use /proc/version, that would be sufficient,
> but then the uname commands probably work for almost every other
> distribution. A generic script won't check package status (which
> in any case doesn't necessarily match the running kernel version).
>
> (We have an even worse problem with kernel tracebacks; they only show
> the release e.g. '2.6.32-5-amd64'. But we could change that too.)
Thanks for explaining. I fear this gets into thorny territory quickly
--- the ideal behavior would be
$ uname -r
3.0.0-2
but it is not uncommon to want to examine the linux-image-$(uname -r)
package and various scripts assume that modules live in
/lib/modules/$(uname -r). Thus a proper fix involves finding a way
for (out-of-tree) modules to be shared between kernels with different
ABI as long as they are compatible with the module, so the ABI version
could be bumped for every stable update. Which is something that was
wanted anyway.
In the short term, though, some hack like the following could help, to
tweak "uname -v" output. (And maybe including UTS_VERSION in
tracebacks as an additional patch, as you mentioned.)
---
diff --git i/scripts/mkcompile_h w/scripts/mkcompile_h
index f221ddf69080..2147f577e6f9 100755
--- i/scripts/mkcompile_h
+++ w/scripts/mkcompile_h
@@ -53,7 +53,11 @@ else
LINUX_COMPILE_HOST=$KBUILD_BUILD_HOST
fi
-UTS_VERSION="#$VERSION"
+if test -z "$UTS_VERSION_OVERRIDE"; then
+ UTS_VERSION="#$VERSION"
+else
+ UTS_VERSION=$UTS_VERSION_OVERRIDE
+fi
CONFIG_FLAGS=""
if [ -n "$SMP" ] ; then CONFIG_FLAGS="SMP"; fi
if [ -n "$PREEMPT" ] ; then CONFIG_FLAGS="$CONFIG_FLAGS PREEMPT"; fi
--
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110822195446.gg11...@elie.gateway.2wire.net
