Fedora 9, May You Live A Hundred Years, Please!

The first article I wrote for LFY in January 2005 was on the need for creating a custom distribution. I would have liked to send my parents an installation CD with just what they needed a CD that did not ask any questions during installation. Obviously, the need was not uncommon. Fedora 7 introduced spins, which makes that possible. I did not use it as I have moved in with my parents, but I now believe the time has come to stop introducing new versions of distributions.

Fedora 9 is on its way but I hope that there will not be a Fedora 10 for many years to come. It is not to say that new developments are not needed. Rather, the manner in which they are introduced needs to change.

The first and foremost is that there need not be any pre-built ISOs. Downloading a distribution should be like creating a spin on the fly. Standard spins can be predefined, not unlike Ubuntu, Kubuntu, Xubuntu, etc. The spin created will have all the updates up to the download date.

Create a spin

Let’s look at how we can create a custom spin. Unfortunately, there is not much to say, thanks to the Revisor package. It has made the creation of a custom distro trivial. However, since I did not wish to download the packages again, I created a little more excitement for myself.

I created a custom repository of all the packages from a DVD and the additional packages I had downloaded. I added that repository to the f8-x86_64 configuration section. I enabled only my custom repository and selected the packages I wanted.

The repository needed to have a group file and I used the group file that came on the installation DVD for my custom repository.
The one difficulty I had was that revisor added the following line in the /etc/revisor/conf.d/revisor-f8-x86_64.conf file:

mirrors =

Although Revisor gave an error in yum, it took a while to figure that the repository was not being used. I needed to remove the offending line.

There was still another small hiccup. Revisor required the joe package, which is no longer included in Fedora 8. After a bit of a struggle, it was easy to fix it by removing the entry from the cfg.py file in the site-packages/revisor directory.

If you have a working kickstart file, pungi is an excellent solution for creating spins.

However, a custom spin is more likely to be created by hardware suppliers and installed on the systems supplied by them. We can now take it for granted that a large number of hardware integrators will provide pre-installed Linux options. They cannot leave the field to major suppliers like Dell, HP and Lenovo or a maverick like the ASUS EeePC.

The kernel as a beacon

We already have the example of the Linux kernel. It is “stuck” on version 2.6 with no signs of version 2.7 on the way. That has not stopped it from being enhanced substantially. The significant advantage has been that the enhancements have been available much faster. That does not mean that the changes have been minor.

Its memory management algorithm changes were hardly minor. The examples of major changes though, are largely invisible to the users. Changing the partition names from /dev/hdaN to /dev/sdaN was a change visible to the users. This change required significant changes in the configuration files of the distributions.

So, the challenge before the distributions is how to manage upgrades so that deployments can make use of the enhancements as they become available. This is not easy because the maintainers have to ensure that the dependencies do not cascade and affect numerous packages.

Managing updates

A major tool in the management of updates for Fedora is the Presto plug-in for Yum, based on DeltaRPMs (introduced by SUSE a couple of years ago). This yum plug-in ensures that the full RPM does not have to be downloaded if only a part has changed. However, a more intelligent update manager may be needed. It should be easy for a user to know which packages have or have not been used. It should be easy to specify about not upgrading to some packages or upgrading only if some conditions are satisfied.

For the last few upgrades in Fedora, the changes have been hardly noticeable. Certainly, the themes have changed. The 3D effects have come in. But operationally, switching from version 7 to 8 was hardly noticeable by my parents. Fedora 8, though, includes the switch to PulseAudio, which is a major change under the covers. This is as it should be because the last thing we need is for the users to have to relearn. So far, no one has succeeded in moving us away from the QWERTY keyboard! The nearest we have come to it is the use of thumbs on the cell phone.

The problems I faced in upgrading were related to PulseAudio and the proper display of fonts in Thunderbird. The distribution builders will have to ensure that even the administrative modifications are easy. It is likely that if we are dealing with incremental updates, it will be easier to visualise the potential problems and plan for them.

When a distribution decides to replace a package with an alternate, the update application should advise the user about the alternate and make it easy to switch.

My experiences relating to the problems with upgrades have primarily been with the packages from third-party repositories. In some cases, a number of packages had to be uninstalled, and then reinstalled after the upgrade. At times, it seemed easier to just carry out a fresh install and then install the additional packages as and when I needed them. The process, in either case, is too disruptive and inappropriate for non-technical users. Further, it would also be inconvenient for the hardware integrators.

It would be desirable for Debian, Fedora, Ubuntu, SUSE, Mandriva, et al to move towards the creation and maintenance of repositories that contain all the supported versions. We buy machines with pre-installed spins. Smart updates ensure that we never have to upgrade or re-install a Linux distribution. Sales and marketing departments will be very unhappy; but Debian, Fedora and Ubuntu don’t have any!