[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!!!)

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.

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.

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.

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?


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