[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]