Upgrades from one major release to the next

[Tarjei Knapstad]

With the inclusion of fedora extras support in anaconda, has there
been any work done to improve upgrading between major releases? Here
are my thoughts on the subject in any case... :)

Whenever someone asks "Is it possible to update my FC4 installation to
FC5?" or the like, the answers are usually one of:

1.  You can do it through yum if you're careful to just follow this
lengthy guide <link to website>, but then again you probably
shouldn't.
2.  Yes, just use the Upgrade option in Anaconda (but you may run into
trouble because of stale packages, configs or whatnot)
3.  The best option is to just reinstall from scratch (you did make a
separate partition for /home, yeah?)

The first option is clearly a mine field and would be very hard to
support, so I think it should just be disregarded for now. I'd be more
interested in improving on the second option.

The current installation document only mentions that "Software which
you have installed manually on your existing Fedora Core or Red Hat
Linux system may behave differently after an upgrade.", which is fine
but doesn't really help the user in any way. As far as I can see, the
potential problems with an upgrade include:

- Some of your packages have been removed (or moved to Extras), and
some new ones might have appeared.

My experience with a FC3 -> FC4 upgrade (of an everything-install) was
that I was left with a lot of stale packages from FC3 and I missed out
on the new stuff like Eclipse on my upgraded FC4 install. Would it be
viable to add a "Review package differences" screen to Anaconda? It
would be nice to be presented with a list of new software that you may
or may not choose to install, as well as a list of stale packages that
you probably want to get rid of or find alternatives for in Extras or
other repositories.

- Your configurations may become invalid (both systemwide in /etc and
per user dotfiles/directories).

Systemwide configurations that are unchanged should probably just be
replaced by newer ones _if they are unchanged_, but I think the
current procedure just installs them as .rpmnew? Would it be possible
to rename the old ones as .rpmold.fc3 if this is the case?
Configurations that are changed by the user should of course not be
replaced, but I think they should be logged to a separate file in the
root account so that it's possible to review these for the user and
check that they're still valid. All this would require sha1 sums of
configuration files from old rpm's so I guess it's hard to implement.

The per-user configuration stuff is harder to deal with. I've had
sufficient trouble with this in the past to generally just get rid of
most (if not all) of my user configuration stuff, and just keep my
documents from /home. No good ideas here really...

- 3rd party software (like Maple in my case), and software that you
have built and installed yourself (worst case: ./configure; make
install) is likely to run into trouble. Maple is mostly "self
sufficient" when it comes to library dependencies, other things are
probably built agains system libraries and is likely to fail. I don't
know of any other solution to this than to warn the user that this
might be the case. Is there such a warning in Anaconda? Or only in the
installation guide?


As for the 3rd option, reinstall from scratch but keep /home, would it
be possible to improve on the suggestion for automatic partitioning to
also include a separate /home partition? If this was combined with an
upgrade option that clearly stated that it will swipe the system, but
keep your /home partition, I guess this would be the most comfortable
upgrade path for many home users. (I agree you should still backup
your data before attempting an upgrade, but why not make it a bit less
likely that you'll have to restore that backup :)).

I'd be interested to hear if anyone else has opinions here and like I
said earlier, if there's any extra effort that has allready gone into
alleviating the pain of upgrades I'd be interested to learn about it.

--
Tarjei