> You're thinking of it in terms of an application again. It's not
> just a "rpm update"... it's a kernel update. RPM can do many things,
> but there are certain things it can't do. I, for one, would not want
> anyone to automate building my kernel. I find the idea scary. When
> my kernel gets updated, I want to know what's going on...
There's nothing to say you can't go in and recompile your kernel - that's
the actual difference between an open-source kernel and closed source. I'm
referencing your last post where you said that it's like comparing apples
and oranges (closed / open source); when I load a kernel that's from the
same distribution and is only a couple weeks newer and I've updated all the
other necessary packages - then things should go pretty smooth. I'm simply
talking about making all the correct symlinks, etc. I think that you're
reading more into what I'm saying than is intended. For example, when I do
load that new kernel via rpm, I have gotten used to having everything in
/boot being updated to reflect the changes (though I still check to make
sure). This is the way I've gotten used to things working, even though
there were probably more steps to it a few years back. If suddenly three
new steps were added to that process, I would think that's a step backwards.
If you look around, I'm sure you'll agree that there are A LOT of things
done in and around the kernel that require a script that the end user knows
nothing about, and for the end user, that's the way it should be (not that
you can't look, but you shouldn't always be forced to). I do like the idea
of being able to customize my kernel, and having an rpm install doens't,
IMO, change that ability. Anyway, it's probably a moot point - it is what
it is. I'm not putting anybody down or bashing anybody's work - it's just
how I feel.
> If an application installed by RPM is messed up, it's easy to deal
> with. Try cleaning up a kernel installation gone haywire and you'll
> see how different it is.
I have ;-) You're right.
> I think that if the directions are clear and concise and easily
> followed (and *work*) then the job is done. I mean, really... how
> long did it take you to follow those instructions? Five minutes?
> Possibly 10? You've got a working kernel now, correct?
Again, not trying to bash anybody's hard work.
> I find that preferrable to someone attempting a quickie RPM hack to
> try and accomplish the same thing, take 1 minute, and find I can't
> boot back into the system.
I'm not talking about a 'quickie RPM hack', I'm talking about an RPM install
of a new kernel; I'm hoping that the people of mandrakesoft (whom I have
great respect and appreciation for) have already made sure to correctly
assemble the new kernel - not 'quickie' hacked it and I do test it before
doing critical work on it. If I wanted to compile my own kernel, I could
download the source and 'hack' till my heart is content. There *IS* a
difference, and I still have the ability to 'hack' and customize my new
kernel that I installed through RPM as much as I want. All I am saying is
that the RPM upgrade of a new kernel should flow smoothly and whether it
only takes 10 minutes extra, it is still more steps. Any time you do
anything, you should look to DECREASE steps, not add more.
Speaking of hacking, let's agree to disagree and not hack at this subject
anymore :-)
Take care, Mike
