David G. Miller wrote:
Jim Cornette <fc-cornette@xxxxxxxxxxxxxx> wrote:
David G. Miller wrote:
or people trying to do an unsupported upgrade (it's unsupported for a
reason).
And the reason being?
The reason is really quite simple: configuration files. Any Linux
distro has to deal with a bunch of them; each with their own syntax,
defaults, quirks, etc. Any upgrade has to cleanly bring forward any and
all user edits and changes in order to be successful. This includes
changes made through the program itself as well as horrible people like
me who fire up vi at the drop of a hat (possibly red) and hack away at
the configuration to get it the way we like it. It's one of the great
things about Linux but also one of the things that means that upgrades
will be difficult unless somebody comes up with a grand unified
configuration file syntax.
I don't edit a lot of configuration files except for grub, xorg
currently by hand. I do use the system tools for most other operations
that change these files. I guess gconf is the great unifier. :-)
If you don't do too much editing and customizing, these things will
frequently "just work". Just don't count on it. I was in charge of QA
for a Linux based network monitoring package at my previous job. I know
how much trouble we had just getting this to work consistently for our
one app. Having seen what it takes to QA an upgrade, I fully support
both Red Hat and Fedora in their decision to not support updates. They
may work; they may not. YMMV.
Early on, I was limited in the use of the CDROM burner I had when
running Linux. The upgrades never added the parameter to load ide
emulation out. Whenever I did my first clean install later on, the CDROM
burned fine. I do see quirks with upgrading and missing out on
technology changes without a fresh and modern configuration. Upgrading
from release version to release version may be supported, but you still
suffer some being left behind. I have no arguments there.
Now, considering the complexity with modern Linux distributions and the
large size of the distributions, installing fresh each time would be a
considerable task.
Since you edit your configuration files to aa great degree, do you just
replace the files from the new install or go through each to note format
changes? Upgrades leave rpmnew or rpmsave files, so short of losing out
on technological changes, what would make one be better than the other.
Merging config files from rpmsave or rpmnew files should serve the same
function.
The other problems are obsoletion and unsupported packages. Rhetorical
question: what should an upgrade do if a user program is now obsolete
and the replacement is one of several different programs? Unsupported
packages are even worse for a distro like Fedora or RHEL. I run
xmms-mp3. What should Fedora or Red Hat do when I upgrade? Hint: their
lawyer may disagree with your solution.
Leave it broken, the application of updates after the install is
finished should allow the program to function again as intended.
Unfortunately, these complaints create a lot of noise that someone
new to the list might mistake for systemic problems.
Maybe there are problems one reads into the postings one may read on
the mailing lists. This is not a forum where one worries too much if
someone puts off upgrading a release because of fears of possible
problems. We are not a propaganda list where only glorious, smooth
success stories are presented.
One glorious, smooth success: I just installed FC6 x86_64 on my HP
laptop (zv6015). It "just worked (tm)". I still have to fiddle with
bcm43xx to get the wireless NIC working but EVERYTHING else worked.
This is in comparison to installing FC4 a year and a half ago and going
through bloody h*** to get it working.
The advancements since FC4 are great enough for me to notice. FC6 in any
manner you choose should be fine. I guess unsupported manners will not
get any bugzilla responses other than unsupported.
Linux ... Freedom of choice, supported or not supported.
Jim
Cheers,
Dave
--
Jones' Second Law:
The man who smiles when things go wrong has thought of someone
to blame it on.
