Feature Proposal: Rolling Updates (was Re: WHY I WANT TO STOP USING FEDORA!!!)
Mark Haney
mhaney at ercbroadband.org
Wed Feb 11 14:08:25 UTC 2009
Alan Evans wrote:
> On Tue, Feb 10, 2009 at 2:35 PM, Mark Haney wrote:
>> No, I understood. But what is masked is what's in rawhide,
>> comparatively speaking. Granted, they aren't identical, but similar
>> enough to where I can confidently say that what's in a base gentoo
>> system is just as bleeding edge. But, I don't want to get into some
>> bizarre flame war over that either.
>
> Help me out here. I've been casually following this thread and your
> apparent line of reasoning leaves me wondering how you think it would
> work out practically.
>
> It seems to me that the closest you can get to rolling updates with
> Fedora is to simply leave rawhide enabled all the time. Now you
> understandably say that this is too bleeding edge -- the packages in
> rawhide are not well-enough tested to be generally used. I agree.
> After all, rawhide is specifically for working out the kinks before
> general consumption.
No, I don't understandably say it's too bleeding edge. I didn't say
that at all. But, I don't mind testing packages.
>
> Fine. So packages in rawhide should be moved continuously into updates
> as each is found worthy of general use? But how? If by the time the
> kinks are worked out, the new package requires libfoo.9, then libfoo.9
> will be updated to replace the libfoo.7 that's in updates. Now
> everything that required libfoo.7 also has to be moved into updates.
> But what if the kinks haven't yet been worked out of those programs?
> And even if they were, one of those programs may now require
> libbar.65, which forces that to replace libbar.56. This doesn't have
> to go very far before it's not considerably different than making a
> formal release. We've gained nothing, and the whole system is probably
> much less stable.
See, that's my point. There is no difference between 'yum update' and
'emerge -upD world' when you think about it. When you update Fedora
between release cycles, you're technically upgrading the system to a new
version. Whether it be a major or minor version is irrelevant for the
point of this argument. If the update to a package is not just a
security update, but an /upgrade/ to a newer version, the OS is
upgraded. And let's not get into semantics here.
>
> As I understand it, Gentoo doesn't suffer this because each user is
> compiling their own package sets. Updating libfoo doesn't require
> recursively redownloading every package that requires it because the
> user already has the source to those programs. He just needs to
> recompile them.
Explain to me how doing an update in Fedora requires the same method?
If I update package 'appfoo' that requires 'libfoo' there's no
difference between downloading and reinstalling the libfoo RPM along
with the new version of 'appfoo' than it is recompiling libfoo in
gentoo. I /still/ have to download the source code to recompile it,
unless I just happen to have that source (and it's not be updated)
sitting in my portage cache. The idea is the same, just a slightly
different mechanism. And with delta packages, this would be a cinch I
would think.
>
> I just don't see how that can work in a general-purpose binary
> distribution. Perhaps you have some ideas about how it can be
> practically done that you haven't shared?
>
See above. Honestly, I've not delved deep into a feasibility study of
this, but I fail to see a rational explanation for why it /can't/ be
done. It makes no difference to me if it /should/ or /will/ be done. I
voiced my opinion and defended it fairly well (I think). If the Fedora
team never goes that route, it's no skin off my nose. I will continue
to use it like I have been since FC1. I like it. It's never been a
pain to use (FF & NM not withstanding) and unless that changes for me
I'm going to stick with it.
--
Frustra laborant quotquot se calculationibus fatigant pro inventione
quadraturae circuli
Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
Call (866) ERC-7110 for after hours support
More information about the fedora-list
mailing list