Rolling Release Model(s), Fedora Discussion

Konstantin Svist fry.kun at gmail.com
Fri Mar 19 21:35:25 UTC 2010


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.


More information about the users mailing list