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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
