On 03/19/2010 02:04 PM, Ranjan Maitra wrote: > > But if that capability is being provided by some other rpm (under a > different name), the rpm update could replace this one with the new > one. For a while, the new could work with the old command, with a > notice/warning to change your habits, and then the old could go away > completely in the next 6 months, let us say? > I'm pretty sure yum already does this for packages which are superseded by others. I'm *guessing* the main problem is what to do if user didn't run yum update for a year and his package A was replaced with B, but then B replaced with C half a year later. Yum repos would then need to keep a very long list of updates so that the user can migrate to B then to C properly -- or quite possibly mess up her system migrating to C directly (because A->C is not officially supported) > Btw, I also was wondering if kernel updates could be split into two > parts: one requiring a reboot and the other not. Would bring us back to > those old *nix uptimes. Of course, it would be better if stuff was > picked up and installed pertaining to the hardware on an user's > machine, that would certainly cut down critical updates quite a bit at > an individual level, perhaps? > I'm pretty sure all kernel updates require a reboot. I've heard of live kernel patching, but not sure if I'd trust it all that much. Complaining about "those old *nix uptimes" is pointless in terms of average user. It's only servers that actually NEED those uptimes -- and guess what, you CAN keep Fedora running for a very long time... I have some FC4 server still chugging away. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
