README - Explain new 2.6.xx.x bug-fix release numbering scheme
Forget the old patch.
Updated the patch to include examples and added a notification about the possibility that a bug-fix release of an older kernel could be released after a new x.y.Z has been released.
Feel free to comment and suggest changes to it, the whole point is to make it readable in a way that normal human beings can make some sense out of it. (Read: Your grandmother)
Daniel Andersen
--
README renamed from README.orig +17 -0
@@ -76,6 +76,23 @@ the backup files (xxx~ or xxx.orig), and make sure that there are no failed patches (xxx# or xxx.rej). If there are, either you or me has made a mistake. + + As of kernel 2.6.8 there was a bug-fix release numbering scheme + introduced. In such cases a fourth number is added to the release + version, eg. 2.6.8.1. When patching from a 2.6.xx(.x) release to a + newer version, patches are to be applied against the original + release, eg. 2.6.8 and not the bug-fix release 2.6.8.1. In case of a + bug-fix release such as if eg. 2.6.8.2 is released after 2.6.9 has + been released, 2.6.9 is still to be considered the newest kernel + release of all current kernels. Old patches can be reversed by + adding the "-R" option to the patch tool. + + Example to apply a bugfix release patch: + bzip2 -dc ../patch-2.6.8.1.bz2 | patch -p1 + + Example to apply a new release on a bugfix tree: + bzip2 -dc ../patch-2.6.8.1.bz2 | patch -p1 -R + bzip2 -dc ../patch-2.6.9.bz2 | patch -p1 Alternatively, the script patch-kernel can be used to automate this process. It determines the current kernel version and applies any
README
Quoted 9 lines · Daniel Andersen
Feel free to comment and suggest changes to it, the whole point is to make it readable in a way that normal human beings can make some sense out of it. (Read: Your grandmother)
README renamed from README.orig +5
-0+ As of kernel 2.6.8 there was a bug-fix release numbering scheme + introduced. In such cases a fourth number is added to the release + version, eg. 2.6.8.1. When patching from a 2.6.xx(.x) release to a + newer version, patches are to be applied against the original + release, eg. 2.6.8 and not the bug-fix release 2.6.8.1.
Perhaps "When patching from 2.6.x.y to 2.6.x.(y+1), patches are to be applied against 2.6.x, not 2.6.x.y."
Chris