[linux-elitists] Stable distro kernel rant
Mon Jan 26 21:11:24 PST 2004
On Sun, Jan 25, 2004 at 06:13:41PM -0800, Rick Moen wrote:
> Quoting Jason Spence (email@example.com):
> > ...so running the bleeding-edge may be a valid solution to this
> > problem for many people.
> Maybe it's just me, but calling 2.4.24 "bleeding edge" strikes me as
> exaggeration to the point of polemics.
I intended "bleeding-edge" in this context to refer to the 2.5.x
series, not the 2.4.x series.
> > The thing I was complaining about was not that it was impossible to
> > run more recent kernels on debian-stable or another branch lacking the
> > latest kernel package in its pool, but rather that porting the
> > packages may be an excessive overhead for one site that I maintain.
> > The fact that make-kpkg isn't exactly the friendliest tool in the
> > world also increases the difficulty of the task.
> I'm not quite sure what to make of this. Are you perhaps trying to pull
> our legs? Compiling a kernel using only the kernel tarball and its
> README isn't really brain-surgery, and make-kpkg makes that slightly
> more automated and easier (as well as inserting a entry into the package
> database) -- but I suppose you could do without that creature-comfort if
> for some bizarre reason you found it too difficult.
I agree that (for me at least) it's not that difficult a procedure to
get the kernel installed from the tarball. Hell, it's downright easy
when I get lucky and yes | make config works for the current release.
But I can't do that, you see :)
The problems I'm concerned about don't involve the actual installation
of a kernel from scratch; they can be summarized as maintainability.
They are, in detail:
- Becoming the sole source of support for the kernel packages. No
one else is using my particular packages, so the only bug reports I
have to go on are from my users (and that's not saying much,
- Doing build maintenance for problems discovered. I prefer to be
lazy in the virtuous sense if at all possible, since it frees up
more time for something less tedious than translating oops messages
and/or undesirable behavior into patch applications (or fixing it
myself). Some people (including me, circa 2001 or so) actually
like doing this. I did so much of it when I did source based
installs on all my personal machines that I've become rather sick
of it at this point.
- Integrating the entire thing with the network boot diagnostic
system, the network booted workstations, the re-imaging software,
vmware, the OS X machines running virtual PC, etc. It's just not
practical to do a source based install on some of these platforms
- Would probably have to maintain a local repository for the
packages, something we currently don't do; we only cache. This
probably isn't that big of a deal, but it is another few days worth
of work to build the hardware, figure out the software, test it,
add it to the NMS, etc.
- Having to fight the urge to implement better maintenance tools.
Maybe make-kpkg is better now, but the last few times I've used it
it took what I felt to be an excessive amount of time to re-learn
how to use it and deal with its quirks (like how it likes to clean
up my kernel directory in between building and packaging).
The last time I got the urge to do fix something like that, I woke
up from my reverie a week later to find I had re-implemented
something like cfengine from scratch :/
- Jason Last known location: 4.5 miles southeast of Fremont, CA
Predestination was doomed from the start.
More information about the linux-elitists