[linux-elitists] Stable distro kernel rant

Jason Spence jspence@lightconsulting.com
Mon Jan 26 21:11:24 PST 2004

On Sun, Jan 25, 2004 at 06:13:41PM -0800, Rick Moen wrote: 
> Quoting Jason Spence (jspence@lightconsulting.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,
   believe me).

 - 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 mailing list