[CALUG] Fedora 11/12 and FF 3.5
Bryan J. Smith
b.j.smith at ieee.org
Mon Oct 19 19:02:05 EDT 2009
First off, I assumed this is why you were looking to do diffs, that
you were bandwidth limited. That's why I mentioned relying on
a LUG fellow for updates on DVD, or ordering a subscription to
CheapBytes or another source.
Secondly, don't forget about Pre-Upgrade[1]. It only downloads
the packages you need to upgrade. With RPM v4.6 diffs (via
Spacewalk server and/or YUM plug-in support), this reduces the
size of the individual packages further. So that's a combination,
with two distinct, but complementary, download reducing features.
Third, Fedora only officially supports upgrading X to X+1. Of
course you can have Anaconda do more than that, or YUM for
that matter, but there are far less guarantees. The whole purpose
of Anaconda[2] is to handle configuration changes beyond what
YUM-RPM (or APT-RPM, SmartPM, etc... for that matter) can handle.
I wouldn't recommend upgrading X+3 or even X+2 via YUM (yum
upgrade, and never yum update) and expecting every thing to work.
With that said, some of us have done it (and even between
Enterprise Linux versions) and only had 1-2 things needing to be
addressed.
Fourth, you should not be running with a Fedora[3] release more than
fifteen (15) months out-of-date or you are a security risk. The Fedora
Project drops updates one (1) month after the release of X+2, giving
people time to upgrade to at least X+1 if not X+2. The "one year
release" update policy has been implemented since early Red Hat
Linux, re-iterated after Red Hat Linux 5, again at Red Hat Linux 7.1
and several times afterwards well into Fedora.
Red Hat - Fedora releases have always been between five (5) and
seven (7) months, with only a pair of exceptions that slipped to over
eight (8) months -- one being the change at Red Hat(R) Linux 10 Beta
1 to Fedora(TM) Test 2 which included various changes from product
to project (including my favorite "clean up" of legacy dependencies
once the product managers were removed from that equation ;).
So ... case-in-point ...
It's best to _never_ be back more than 1 year. As I've iterated, and
re-iterated and reminded and re-reminded people since the initial
Red Hat Linux 6.2 "Enterprise Edition" (3 year Service Level
Agreement version, retroactively called Red Hat Enterprise Linux 1)
came out, you need to be rotating servers every year if you're using
the leading edge community distro release.
-- Bryan
[1] Pre-Upgrade is the Anaconda installer, only it pre-fetches
the RPMs and installs itself as a GRUB boot option. I.e., you boot
from your hard drive into Anaconda, with only the packages you
need.
[2] People debate APT-DPKG v. APT/YUM-RPM when it
comes to "apt dist-upgrade" (DPKG) v. "apt dist-upgrade" (RPM)
v. "yum upgrade" (not update, YUM != APT, never assume the
options remotely work the same, or the tool for that matter) for
upgrading entire releases, and the purpose of uber-tools like
Anaconda that do all sorts of things (not just an installer, but a
system builder in reality). My take has always been the Debian
package guidelines have always been key to many aspects of
APT-DPKG being the best at package updates, including config
and full distro updates -- second-to-none. However -- as most
people find, the Anaconda installer is virtually perfect at X to X+1
(at least for anything included in the 12,000+ package Fedora
Project, which is a crapload larger than it was just a few years ago
before the unified system and contribution approach -- let alone
when you add in the "Non-Free" of RPM Fusion). In other words,
no I don't see APT-RPM or YUM-RPM being remotely as good as
Debian (I'm not even going to visit Ubuntu here) at APT-DPKG
for full version upgrades, but a lot of people swear by Anaconda
for X to X+1 (let alone chroot installs, distributed rollouts, etc...),
including myself (and especially compared to non-Debian APT-
DPKG where the guidelines and attention are different ;).
[3] There is no "Fedora Core" distribution anymore starting with
Fedora 7. The build and community system are completely unified.
It's even used to feed non-Red Hat subscription, but Enterprise Linux
focused, build/community options like Fedora's EPEL (Extra
Packages for Enterprise Linux). So it's best to refer to it as F7, F8,
F9, F10, F11 and F12. The only time I note the "c" still used is
when there is a reference to the core ABI/API such is in a disttag or
core subsystem (and then .fc11 in lowercase), largely to match the
common, two digit expectation of disttags (long history short).
----- Original Message ----
From: Walt Smith <waltechmail at yahoo.com>
I'm thinking ahead.. when the release happens.
I do have dialup only.
When I had FC6, I didn't see any reason to upgrade
to FC7, or 8. I upgraded to 9 only because I had an
itch and wishful thinking. I then upgraded to 10
because I had access to a high speed line and a DVD burner.
And could D/L the updates: I usually like to wait about a month
after the initial release before I get the iso + updates
so the worse kinks are gone.
The release is mid-November, so I'm just "shopping" at the moment.
i.e. looking for a reason !!
Will Fc12 really be worth much more for my purposes.. ??
PS: I'm writing lots of small C# programs in mono so my desktop is also
a development station.. I mean, like under 100 line programs,
all CLI oriented, no gui's.
thanks,
Walt........
More information about the CALUG
mailing list