Please, take the time to intersperse your replies. Top-posting makes it harder to follow.
On Fri, 2008-10-03 at 17:39 -0700, Fong Vang wrote:
So you're saying that the CentOS 4.x system is married with the 2.6.9 kernel?
No.
Maybe the packaging of the kernel RPM is different between 4.x and 5.x, but why would a 5.x kernel not work on a 4.x system, especially considering you can always download the latest kernel from the kernel source tree and run that so this doesn't sound right.
I don't believe rpm packaging is an issue. As long as prerequisites are satisfied, rpm would do its thing.
Anything is possible. And may even be easy. The CentOS wiki has a page on making your own kernel. *Usually* this is done within the same major branch, for good reasons. Often it is just to enable some feature which is disabled by default by upstream. Within the same major kernel version, this is often no problem as efforts have been made to avoid breaking ABI by the glibc and kernel folks.
Expand your consideration to a system view. Kernel provides basic functions and management. To use these, system calls are used. These have required parameters. They must have the right attributes, order, etc. Most of these interfaces are provided through a set of libraries, glibc being the predominate one, that provide an Application Binary Interface (ABI) made to match a major kernel version. This does insulate, to some degree, the applications from changes in the underlying kernel. Applications can make the system calls directly and, thus, are not insulated if they do so. If if that is not done, there are limits. If the kernel changes are too great, relative to the specific version of glibc and other libraries, the binary interface may be broken in certain areas.
If you upgrade the glibc (and any other needed libraries - might be only a few, I don't know) to support the kernel, then the applications may need to be recompiled to use the new libraries. And other libraries that depend on glibc, and other apps/libs that depend on those, and other ...
None of this is certain. In C (and C++) which, IIRC, is the language used, there are techniques that can allow for certain types of mismatches. But this does take more code.
I just need the later kernel, not the new glibc which will break compatibility.
Like the other person said, give it a shot. But as he said, use a test system.
Last, consider the following. System maintenance. As upgrades occur in the kernel and/or libraries and applications, you may have a maintenance nightmare. One very small change in any of the components may render your system unreliable or even not runnable. You may have to maintain many sources yourself. Even 1 source may be tough. Automatic updates may not be at all feasible. You may miss, or be unable to install, critical security updates or fixes without great effort.
Summary in "real world" terms: you can't stick the pistons, conn rods, intake manifold, ... from a 1966 Pontiac GTO (389 c.i., tri-power, ...) in a Ford 302 very easily. :-(
So, just proceed with caution, consider long-term impact and how smart or dumb you might appear to those who matter later on.
If the later kernel is your *primary* factor, build (beg, borrow, steal) a system around it.
<snip>