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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
