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 checkes 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. > 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. > The summary is, this is a distro problem to solve, and it's > within their power to solve it without changing rpm. Agreed. Bob _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
