Messages in this thread | | | From | Frans Pop <> | Subject | Re: Linux 2.6.32-rc3 | Date | Thu, 15 Oct 2009 17:51:01 +0200 |
| |
Ingo Molnar wrote: > hm, i think you ignored (or missed, or found irrelevant) my first > suggested variant: > > v2.6.31 > v2.6.31+
A general concern about adding the "+".
Anyone want to bet how many (init?) scripts there are in userspace that do something like:
KVERS="$(uname -r | cut -d"-" -f1)" case $KVERS in 2.6.*) minor=$(echo $KVERS | cut -d"." -f3) if [ $minor -lt 10 ]; then # do something fi ;; esac
Note that the '[ $minor -lt 10 ]' will now produce an error because '31+' is no longer a valid number: bash: [: 31+: integer expression expected
A "-" has for ages been the standard separator between the kernel version and any suffixes, certainly in Debian. Loads of scripts will assume that.
In an earlier mail I said that I would consider using the "+". This is seriously making me have second thoughts, even for custom built kernels.
Here are some real life examples from my Debian stable system: /etc/init.d/pcmciautils: supported_kernel() { case $KERNEL_VERSION in 2.[012345].*|2.6.[0-9]|2.6.[0-9][!0-9]*) return 1 ;; 2.6.1[012]|2.6.1[012][!0-9]*) return 1 ;; esac return 0 }
Would have failed for e.g. a 2.6.12+ kernel.
/etc/init.d/umountnfs.sh: KERNEL="$(uname -s)" RELEASE="$(uname -r)" case "${KERNEL}:${RELEASE}" in Linux:[01].*|Linux:2.[01].*) FLAGS="" ;; Linux:2.[23].*|Linux:2.4.?|Linux:2.4.?-*|Linux:2.4.10|Linux:2.4.10-*) FLAGS="-f" ;; *) FLAGS="-f -l" ;; esac
Would have failed for e.g. a 2.4.7+ kernel.
Sure, these won't fail if we start adding the "+" now, but will the people writing such tests in the future always remember to allow for the "+", especially given that it will be relatively rare in a distro context?
Cheers, FJP
| |