Episodes from the evolution of Fedora

One of the core developments in Fedora 7, so to speak, is the merging of the "Core" and "Extras" distributions. As of the next release, it is all simply "Fedora." Given the nearness of the release, one would have thought that this merger would have happened some time ago. As it happens, that merger is just being finished up now. Much of the ground work was done over the preceding months, leading up to the actual joining of the repositories, source management subsystems, and build systems happening now. As of this writing, the new source archives and build systems are up, but the flow of packages into the Rawhide distribution has not resumed.

There has been a small amount of concern voiced by a few maintainers of packages formerly found in Extras. In the good old days, they could post an updated package at any time and have it go right into the repository. Now that there is only one repository, the whole thing is currently frozen in the run-up to the release. How to work in the new, unified environment is still not entirely clear to all Extras package maintainers. Overall, though, the number of glitches from the merger appears to be small - so far. More information can be found in the draft post-merge FAQ.

Red Hat's distributions have long been known for including software which is not necessarily completely mature. Over the years, this company has pushed in bleeding-edge technologies like ELF binaries, glibc2, SELinux, and more; the end result has often been a combination of user pain and accelerated development of the code in question. Fedora is in many ways the true descendant of Red Hat Linux, and it continues the practice of packaging very new technologies. Some users are beginning to wonder if that practice has gone just a little too far this time, though.

The software in question is the Nouveau driver. This reverse-engineered code is an eventual replacement for the binary-only drivers supplied by NVIDIA. Someday, Nouveau will be the driver of choice for people with NVIDIA hardware, but today is not that day. The Nouveau driver is still in heavy development with a lot of problems to solve before it is ready for production use. But Fedora 7 includes it anyway so that people with an interest in trying out the new driver can do so.

Fedora 7 does not enable Nouveau for any system unless explicitly told to. In theory, anybody who turns it on should know what they are getting into; in practice, at least one user has already been burned by trying Nouveau in a situation where it did not work. So some voices have been heard to say that Nouveau has been included ahead of its time and should be removed. Fedora developers still want to include it, though:

Others say that a project as important as Nouveau should not be subjected to a tide of disappointed users who were lulled into trying the code before its time by their distributor.

Chances are that Nouveau will remain. There is one remaining issue, though: Nouveau is currently co-packaged with the stable "nv" driver that people are actually expected to use. So Nouveau cannot be updated without pushing out a new nv package. Given that Nouveau can be expected to evolve considerably over the life of Fedora 7, impediments to the packaging of updated versions seem like a bad idea. There is talk of splitting Nouveau into its own package, which seems like a more than reasonable way of solving this problem.

Finally, there is the issue of Python 2.5. That is the current version of the language, and the version which will be shipped with Fedora 7. The only problem is that the Zope content management system, which serves as the base for Plone (and others), does not work with this version of Python. So the current plan is for Fedora 7 to ship without Zope or the packages which depend on Zope.

Back in the days when Red Hat Linux fit on a single CD, a core component like Python would not have been updated until everything which depended on it was ready for the change. In fact, Red Hat Linux was glacially slow to move to Python 2 for just this reason. Fedora is a much larger distribution which lacks the same sort of firm central control, so it has become much harder to delay an update like this. And, unlike Debian, Fedora is unwilling to delay a distribution release until all such issues are worked out.

Some Zope users would like to see Fedora ship a "compat-python24" package so that Zope will continue to work. There is some opposition to this idea, though:

Jeremy Katz, the maintainer quoted above, would like to see a rule allowing a package maintainer to veto the addition of older "compat" packages so that they could avoid having to deal with these sorts of problems.

He seems likely to win this particular argument, meaning that there will probably be no Python 2.4 in Fedora 7. The implication is that interested people will end up creating a set of Zope and Python 2.4 packages for Fedora 7 and hosting them on a third-party server somewhere. It will be a small amount of extra hassle for affected users, but that can be worked around. The issue of security support (crucially important for a complex, network-facing system like Zope) should be considered by anybody wanting to run this code, however.

There have been suggestions that the maintainer of the Zope package should undertake the task of making it work with the version of Python found in Fedora 7:

In this view, making Zope work with Fedora's version of Python is much like making it work with SELinux or Fedora's init scripts setup - just part of the job of making a package for the distribution. Once again, this role was probably easier to carry out back in the single-disk days. In any case, the current Fedora Zope maintainer is not going to port Zope to Python 2.5 - that is apparently a rather large job.

This, too, will pass, and Fedora 8 may well be able to welcome Zope back into the fold. In the mean time, though, the Fedora developers are trying to figure out just how their distribution should react to issues like this. As Fedora evolves and becomes more open to the community, it will have to better define its policies and set them down so that developers know what to expect.