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

Bill Davidsen wrote:
Mark Haney wrote:
Alan Evans wrote:

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.

No, this isn't semantics, there are four things involved here, not two:
- the OS is really just the kernel. In general you can update that
without breaking everything. But if ACPI or similar changes, then
some apps or scripts may fail.

Really? Oh no, I thought we covered that several threads up. The
kernel is understood. No one is questioning that and for the most part
I was NOT talking about the kernel. I hate repeating myself.

- applications. Changes and upgrades to one application can be made
freely, since they don't impact other things. Unless, of course, they
need a change in...
- libraries. Changing a library means you have to control every application
which uses the library. Since that may include user applications, non-
Fedora applications, commercial databases, etc, that means that there is
a very high chance of breaking things if a library is upgraded (as
opposed
to bug fixes, and other changes which don't change the API or behavior).

Again, I am well aware of libraries. But Fedora handles library updates
just fine 'between releases' so what's your point exactly? To me
updates that are done to a system say, between F9 and F10 are nothing
more than rolling updates. Is this not so from any standpoint? And if
not, explain to me how it's not? During ANY update you do on your F10
system libraries are affected. So I see no difference doing continuous
updates this way and the current method Fedora uses with updates to a
'version' between releases.

- the distribution. The things which make one Linux different from another,
including package management, graphics, window manager, location of
system files, graphics, system features like udev, SElinux, boot scripts
and files, compilers and interpreters like C, perl, and python, and other
things which have to all stay compatible with one another.

What does this have to do with rolling updates? We are talking about a
specific distribution here. That should have been understood, I would
have thought. Under no circumstances would I try to use a Fedora RPM on
my gentoo box. So this bit is irrelevant.


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.

Compiling solves little, unless you mean compiling every application on
the system each time you change a library in a non-trivial way. And of
course if you change the compiler itself, there is no promise that
multiple things don't break. Just look through the rawhide change
listing and search for gcc, perl, and python, with notes like "fixed
issue with gcc x.x.x" indicating that the application couldn't just be
recompiled with the new compiler and library, source code changes were
needed.

Compiling only is important to a distro that compiles from source
everything. Fedora builds binaries and makes the binaries available.
So exactly HOW does Fedora handle GCC updates? Surely they are not
using the same GCC as FC1 used? I suppose it's possible they move to a
new GCC for a new release and not in the middle of a release, unless
it's a rev update and not a major version. Again, I mentioned
'profiles' in Gentoo. For me, F10 is a 'checkpoint' of versions and
libraries from which the new updates are going to build on. The concept
is the same in Gentoo. Granted I control updating GCC and for a major
update (which I did last week) I had to rebuild the entire system for
the libs to all be the same GCC version.

So, let's assume rolling updates from F9 to F10. All an 'upgrade' does
is setup the baseline binaries and libraries that F9 must have on it to
qualify for F10 status. Sure, there are 'release' files in /etc/ but
that's irrelevant for the purposes of this discussion.

No, what's the difference between I manually updating my F9 system to
the exact same versions and kernels, etc that F10 shipped with? And
upgrading to F10? Wouldn't my F9 box be F10 in all but name? I
certainly think so. In fact, isn't that what preupgrade does? Or the
apt-get method in Ubuntu?





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.

Hopefully the above is deep enough delving to assure you that new
releases from time to time are actually the least painful way to go.

I'm not sure I agree that it's less painful. I have to take down my
servers to do an upgrade from Fedora. With preupgrade I can keep the
system up during a large portion of the upgrade process and that's
better. I don't know we'll ever get to the point where we don't have to
reboot to get the latest kernel, but I'm hopeful.

Again, new releases are fine. Gentoo has releases as well. They are
just not as painful a process to 'upgrade' to. Sure, it's a different
designed distro altogether. compiling from source eases and complicates
things in different ways than binary offerings. A checkpoint to me is
still a checkpoint. I'd really like to see Fedora work more toward
streamlining the 'upgrade' process online instead of relying on DVD
ISOs, etc.





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

Relevant Pages

  • Re: Preferred Method for Recompiling Apache on FC3?
    ... >> dependencies and hosing my system the next time the httpd package is ... > epoch number on your custom RPMs, so that updates from Fedora never ... I agree with Darren that tweaking the httpd SRPM is the way to go. ...
    (Fedora)
  • Re: rkhunter warning after updating
    ... updates on those applications and update your config each time one ... changes in fedora. ... package be installed instead of a custom build for that matter. ... the updates and when someone applied the rkhunter one. ...
    (Fedora)
  • Re: Easy way to update Fedora
    ... >>What is the easiest way to update Fedora. ... >>about yum but it has never worked for me, ... > packages or type a package name ... > UPDATES TO SYSTEM AND PROGRAMS: ...
    (Fedora)
  • Re: fedora package v upstream source
    ... If upstream have parts of their code that have incompatible licensing, then the fedora package might exclude that part. ... A fifth difference is our policy to exclude statically linked libraries from Fedora builds. ...
    (Fedora)
  • Re: rkhunter warning after updating
    ... changes in fedora. ... package be installed instead of a custom build for that matter. ... the updates and when someone applied the rkhunter one. ...
    (Fedora)