On Fri, 2004-06-18 at 21:07, Bob Proulx wrote: > Wichmann, Mats D wrote: > > There are other approaches. Many distros seem to distribute > > kernel rpms named in such a way that a new kernel doesn't > > look (to rpm) like a newer version of an older one, and so > > updating in place just doesn't work. With -A running, install -B, > > reboot, if everything checks out you can delete -A. > > > > I suspect this means that too many users have gotten > > bitten or they wouldn't be doing this. > > It has nothing to do with being bitten. It has to do with working > with the tools as they exist. Naming kernels uniquely just seems like > the right thing to do to me. I generally want things to be > automatically updated. But I don't want the kernel to be > automatically updated. At the least I will need to reboot afterward > and so kernel updates are at this moment still something that takes > human intervention to complete. I even want the kernel updated automatically, but the old kernel only removed when it is no longer running. I just find it annoying that the /lib/modules/$(uname -r) directory tree is removed from under my feet. I want to be able to use the running kernel until I decide to reboot. True, a human intervention is required to reboot. As soon as a newer kernel has been installed, the up2date thingie in the panel begins nagging me that I am running an older kernel than the latest installed one. (I have not checked what the thingie does if I have two kernels installed.) I want a system that does not rely on me _remembering_ all sorts of arcane details. I want the privilege of being just stupid, sleep-walking through my chores, yet get most things right automatically. What else is the computer invented for? > > Now if distros would be a little more cautious what they add... > > maybe we could count on replacing the kernel with a supported > > update as not being a recipe for disaster. > > The method to do that within the current packaging system is to use a > generic metapackage and something like apt or yum. The meta package > requires the latest kernel. APT will upgrade the generic meta which > will pull in the latest kernel. Everything works and you get > automatic kernel upgrades. The last kernel will still be available > until cleaned off. So the only downside is that you can collect up > a long list of kernels on the machine until you clean. This sounds like a possible way. The cleaning isn't hard to automate. If uninstall can be cancelled from inside the scripts, it would not be necessary to play games with the package names or use metas. I have not yet gotten around to try what happens if the %preun script exits with a nonzero exit code. I could not find anything about that in maximum rpm, except the statement "It's even possible to use the scripts to perform tests to ensure the package install/erasure should proceed." Is there any documentation of this? Even if the uninstall cannot be cancelled, all paths in the kernel package (I use FC2) have the kernel version string, so the %preun script could rename them, and the %postun could then rename them back, and some /etc/rc.d/rc.* script could remove the files once they are no longer needed. With this solution the old kernel package would appear to be removed, and the files orphaned, belonging to no package, until they would be gone. Regards, Enrique _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
