Suppose you want to build a new kernel RPM that incorporates a different kernel (slightly up or down from distribution baseline). You want to turn off all their patches, and simply build the kernel, the headers, the -devel, …
Can you do it?
No I am serious… can you do it? The following is a bit of a rant. Borne out of frustration with things that are designed broken (IMO).
Part of the problem is, not surprisingly, RPM itself. The other part of the problem comes from the spec file. In the simplest sense, a spec file details where things come from, and how to build them.
We have built a number of packages as RPMs, and it hasn’t ever been simple, even if building the package was as simple as “./configure ; make ; make install”.
This presents, well, at best case, a significant problem … no … call it a barrier … to delivering functionality. You cannot *easily* modify the kernel rpms, in order to incorporate new drivers, or downrev the kernel to support a driver.
Say for example, downreving the Fedora 9 kernel to 2.6.24 to be able to support Infiniband OFED stacks.
Nah, that wouldn’t be useful. Not at all.
So far the *only* sane distro kernel build system I have seen for a distro has been the ubuntu version. This is based upon Debian.
Outside of the distro build system, we can build linux kernels just fine. Its the package manager that gets in the way.
RPM has been a pain for us for years, and we have stuck with building with it. I think it is high time we rethought package management, specifically the implementation of RPM. As it is, it is IMO horribly broken. Just look at a recent kernel source rpm. This is not a thing of beauty or elegance. It is a cave filled with razor sharp edges and no lights, just waiting to open up a few blood vessels.
I’ll revisit the build and use our own SPEC file. A minimalistic spec file.
Maybe I can use alien to convert our Ubuntu .debs into .rpms without having to go through the horrible build process known as RPM.