Re: tlug: Patching the RH6.0 kernel

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Simon" == Simon Cozens <simon@example.com> writes:

    Simon> On Sun, Nov 07, 1999 at 05:25:47PM +0900, Dennis McMurchy
    Simon> wrote:

    >> I've had a look on the RedHat site, but see no sign anywhere of
    >> patches.  This shouldn't be hard at all, but I've noticed that
    >> nothing's easy with this RedHat stuff.  What am I to do?  I

Red Hat is not interested in making things easy for power admins.
There's no money in people who can do stuff for themselves, and if
they want a CD-ROM, they make it themselves (or buy from CheapBytes).

    >> would hate to think that I wasted my time downloading all those
    >> patches from sunsite.

You haven't, although I would just chuck the Red Hat kernel package
(but not farther than a subdirectory of /var/tmp, see below).

    Simon> Seems like what you're trying to do is have the best of
    Simon> both worlds; to have the RedHat
    Simon> packaged-up-and-(hahaha)-fixed version of the kernel
    Simon> source, but also be able to patch it yourself too.

This works pretty well under Debian, actually.  But then, Debian
has an explicit policy against hacking any upstream package; they
figure the admin will do that.  I've generally found it possible to
use the Debian patch for the latest Debian version on the latest
upstream version (often from a development branch) with _no_ hand
application of patches from Debian.

Also, for kernels, Debian assumes that you _will_ be hacking the
kernel (if only by changing .config), and provides the kernel-package
package which automatically builds a Debian packages from any
unpackaged kernel source.  It's not perfect, but it is preferable to
either building a kernel and discovering that preexisting control
files have done something horrible to you, or doing without package
management.

    Simon> Incidentally, if you have the RedHat SRPMS, the SRPM to the
    Simon> kernel-source RPM will contain the original sources,
    Simon> separate from the RedHat patches that are giving you
    Simon> trouble.

Actually, the patches are the only valuable thing in an SRPM.

What I would do (have done, with X11R6 and libc5 for sparc) is unpack
the SRPM into a temporary holding pen.  Ditch the sources and the
control files, just keep the patches.  Then unpack the freshest (up to
stability) source you can get into the source directory.  Check out
which patches are interesting (the patches are often mail messages
with information about what they're good for, and definitely should
have comments explaining what bug the change fixes).  If you can't
tell from Documentation/Changes which patches made it into the kernel
you've got, then apply them one by one checking to see which ones give
you "reversed patch" notices (omit them) and which ones give you lots
of rejected hunks (save them and think about what to do later).

Now rm -rf that whole hierarchy, heaven only knows how you've
mutilated it.

Unpack the kernel again, and start applying the patches you want.  Fix 
all rejected hunks by hand before applying any further patches, and
continue.

make config; make bzImage, and pray.  ;-)  It worked for me with both
X11R6 and libc5 (although not very well with the latter).

    Simon> Please note, I'm not knocking RedHat here; they provide you
    Simon> with turn-key solutions. If those turn-key solutions aren't
    Simon> actually what you want, then it's sensible that you may
    Simon> have to go about things a different way.

But Simon, what if I want a turn-key solution, not a turn-key SIGSEGV
factory?  ;-)

Seriously, Red Hat and TurboLinux (and probably all the non-developer
oriented distributions) really ought to make things a bit more
orthogonal.  But I don't think they will, it'll just evolve in that
direction as developer customization tools become more user-friendly.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."
-------------------------------------------------------------------
Next Technical Meeting: November 13 (Sat), 13:30 place: Temple Univ.
* Network Security                               speaker: Steve Baur
Next Nomikai: December 17 (Fri), 19:00 Tengu TokyoEkiMae 03-3275-3691
-------------------------------------------------------------------
more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan