On Sat, Aug 05, 2000 at 04:25:29PM -0700, Mike & Tracy Holt wrote:
> > 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.
Oh, I know you're not bashing anyone... I hope I didn't give the
impression that I was being on the defensive here, I'm just trying to
give an alternate view to it.
I think if you do an rpm -Uvh of your kernel packages, it'll do all
the proper symlinks and everything. I think everyone here at
MandrakeSoft would agree that upgrading a kernel is a bad idea,
especially a cooker kernel. =) That's why we recommend installing
the new kernel alongside the old, which makes it a little difficult
to be more "interactive" and setup some stuff automatically. Things
like that should be left to the user and not "assumed" by an RPM
installation. If I install a new kernel, I don't want my symlinks
overwritten... they currently point to a working kernel. I'd rather
throw an entry in lilo.conf pointing to the new kernel and use
"linux-test" to label it. I think the one thing that could be added
would be to auto-generate initrd upon the install, but some people
don't use/need initrd, so that's extra overhead to just arbitrarily
decide someone needs it.
> > 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.
Yeah, it's not too much fun. =)
> > 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.
Not saying that you are, Mike. You obviously want something a little
easier to deal with... but so do I. I would prefer a nice smooth
upgrade path for kernel updates as well. It would certainly make our
lives easier, not to mention the end user who we're doing all of this
for.
> > 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.
Very true. But you can only decrease so much. And if adding more
steps is the only reliable way to accomplish something, then we have
to consider that as well. I'd love to make it completely
un-interactive... fire up MandrakeUpdate, walk away, come back and
everything is done. Heck, I'd love it if you could install a new
kernel and not require a reboot! That would totally rock!
Unfortunately, we're not quite there yet.
> Speaking of hacking, let's agree to disagree and not hack at this subject
> anymore :-)
hehehe... you got it. =)
--
[EMAIL PROTECTED], OpenPGP key available on www.keyserver.net
// Danen Consulting Services www.danen.net, www.freezer-burn.org
// MandrakeSoft, Inc. www.linux-mandrake.com
1024D/FE6F2AFD 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD
Current Linux uptime: 2 days 9 hours 36 minutes.
