Side By Side

Summary

Allow two different versions of Fedora to be installed on one machine so that either can be booted without effecting the other installation.

Owner

Name: Carl Sopchak

email: carl.sopchak at cegis123 dot com

Current status

Targeted release: [[Releases/Template:12 | Template:12 ]]
Last updated: March 27, 2009
Percentage of completion: 0.0%

Detailed Description

When I upgraded from FC6 to F8, I decided to create a separate partition for the OS upgrade. I set up separate partitions for the /home directory and some other file systems that I had. This allowed me to dual-boot FC6 or F8 with equivalent environments, except for the OS. This worked pretty well, and was extremely useful during the upgrade and re-setup process. I could work on porting configuration to F8 without worrying about getting the machine to a stable, operating state in any given time frame. (My time is limited...) I could always boot FC6 to get a usable machine.

When I upgraded to F10, I overwrote the FC6 partition, and expected the F8 to remain more or less stable. Unfortunately, that was not the case. There were several significant issues with rebooting into F8 after having booted and logged in to F10. (Namely, the windowing system "lost" the main window controls, which wasn't too difficult to get back, and kmail lost the account setup, which took a while to correct. Thank goodness for backups! I'm sure there are others that I haven't found yet.)

This is a feature request to allow Fedora to be installed in a similar side-by-side manner such that one release will not modify another release configuration. Ideally, such a side-by-side install will recognize the prior install, and copy configuration information to the new install as needed.

The rest of this section is more or less a brainstorm of how this might be accomplished... I am by no means a guru Fedora System Administrator, so other suggestions are more than welcome...

1) The creation of the file /etc/release, which would contain a directory name used specifically for the current release (e.g., "F12"). Also have a /etc/prior-release file with the previous release installed (e.g., F10). This allows for non-incremental upgrades (e.g., F10 to F12, without F11).

2) For system-level configuration, move /etc/sysconfig to /sysconfig (or not), and making it a mountable filesystem, allowing it to be shareable between releases. There would be first-level subdirectories that are the value(s) of the /etc/prior-release and /etc/release values, with the current /etc/sysconfig directory tree underneath.

3) User configuration files would be under ~/.{release}/{normal subtree}.

4) Change Anaconda to ask (or detect) if a prior release is installed, and include packages from the prior install (in the most recent version, of course). Ideally, this would include disk partition manipulation to set up multiple partitions for the side-by-side install, even if that was not originally planned. (I.e., shrinking existing file systems, creating a new partition for the new release, etc.)

5) The biggie: Applications would need to be modified to use this new configuration location. New software installed would have a default configuration file under {normal config file name}.default. When run, software would check the normal config file name (under the right release subtree). If not there, it would first check the prior-release subtree, if it exists, and lastly the default configuration file. Whatever is found first would be copied (or converted from the prior release, if necessary) to the normal configuration file (in the current release subtree), and therefore be used henceforth.

Benefit to Fedora

I can see a couple of benefits to this setup:

1) Upgrading would be substantially simplified (my main goal...). I currently skip every other release due to the work involved in upgrading. It provides a safe fall-back should issues arise during an upgrade. (I can't recall an upgrade where at least one issue has popped up...) Most reconfiguration steps would be eliminated because the prior configuration would be used (if it existed).

2) Fedora recommends doing a fresh install for each release. More people would be willing to do so if it was no more work than an upgrade over an existing release.

3) This would provide a way to check bugs or features or whatever between releases.

Scope

Unfortunately, I am not familiar enough with how things like configuration file locations are determined/specified in projects to know the scope of the changes involved for the various components, or how to go about getting such things changed...

How To Test

Each package would need to be tested using multiple "release" and "prior-release" file combinations. I think this can be limited to "prior-release" less than "release" (although going backwards, to a point, could be useful...).

Ideally, the ultimate test would be to install the "next release", boot it and verify all prior configuration and packages are available and working. Then, boot the prior release and ensure there are no artifacts of booting the next release.

User Experience

The user experience would mainly be affected during an install/upgrade: They would have to provide indication as to if a prior release should be used for an upgrade. That response would change the remainder of the questions during the install process (like, ask nothing else if upgrading, and get everything installed and configured correctly).

The user experience would also change in that they could boot into the prior release.

Dependencies

Virtually all configurable packages within the distro.

Contingency Plan

Changes to individual packages, I believe, would be minor, and reverting to prior version behaviour would be acceptable and trivial. These changes could be implemented piecemeal without Fedora claiming to be "Side-By-Side Capable", until all packages are ready.

Documentation

(to be developed)

Release Notes