[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Feature Proposal: Rolling Updates (was Re: WHY I WANT TO STOP USING FEDORA!!!)

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]