Rethinking Fedora multilib support

The Fedora Modularity effort is bringing changes to the distribution, particularly in order to build these modules that will encompass a "unit of functionality" such as a web server. An ongoing discussion on the fedora-devel mailing list is looking at the pros and cons of changing the distribution's longstanding multilib mechanism, which is what allows 32 and 64-bit libraries to coexist on the system. An initial proposal to use containers as the new mechanism was shot down quickly, but other possibilities are being discussed. Where it will all lead is anyone's guess, but as noted in our December look at the possibility of annual Fedora releases, the project is clearly considering and discussing fairly massive changes going forward.

The proposals have come from Stephen Gallagher, who posted the first, container-based idea on January 5. In it, he suggested that, instead of separating libraries into /usr/lib for 32-bit libraries and /usr/lib64 for 64-bit ones, there should be a shared 32-bit container runtime used to run 32-bit programs on 64-bit systems. That idea swiftly ran aground.

Gallagher outlined some advantages and disadvantages of the approach, but complaints were immediately heard about programs like Wine, Steam, and Skype that require 32-bit OS support and are not likely to be containerized anytime soon. Beyond that, though, it would fundamentally change the way 32-bit applications are built on top of Fedora. Instead of using the -m32 GCC flag and the relevant 32-bit libraries in /usr/lib, some kind "special dance to enter a container environment" would have to be done, as Tom Hughes put it. In the end, there are no real user benefits, Ben Rosser said:

The fast reactions in the thread led Gallagher to put out a second proposal roughly six hours after the first. He summarized the objections raised to the first proposal and listed two alternatives that had been proposed in the thread. The first would adopt the Debian Multiarch mechanism, which uses a /usr/lib/$ARCH-linux-gnu directory scheme. One advantage to that might be the emergence of a de facto standard between distributions. The other suggestion from the thread was to default installations to a single architecture (i.e. 32 or 64 bit) and only install libraries for that, but to allow additional architectures to be enabled in the DNF package manager for those users that need them.

As Gallagher noted, the two are not incompatible and, in fact, "their combination may indeed prove to be a superior solution to the one I initially came up with and suggested". He then went on to point out some problems that the transition would engender, but called them "surmountable". Moving the libraries would likely require leaving some symbolic links behind for binaries that expect to find them in /usr/lib[64]. RPM specification files may need to be adjusted so that the wrong versions of dependencies don't get installed during times when the i686 and x86_64 mirrors are not in sync. Also:

There were complaints that the Debian library directory structure does not follow the Filesystem Hierarchy Standard (FHS). But Gallagher seemed unconcerned about strictly following the FHS: "we try to stay as close as possible to it, but if it doesn't meet our needs, we'll work around it". Hughes thinks the Debian organization is clearly an improvement, but is not so sure about making a switch:

But Bill Nottingham is concerned that the change is being motivated only by build problems for Fedora and may not be keeping users firmly in mind:

While it is true that build problems are motivating Gallagher to look at the multilib support, he definitely does not want to leave users behind:

There is still opposition to the whole Modularity idea, however, especially from Kevin Kofler. Most participating in the thread seem to be on board with the plan, but Kofler, as he often does, sees things differently:

As part of the discussion, Langdon White pointed out that, for example, there is no real need for KDE and httpd to be tightly integrated, but that the current Fedora model forces the two to share libraries. Florian Weimer expanded on that:

As Fedora project leader Matthew Miller said, that is an example of where the distribution has hobbled itself "in our well-meaning attempt to integrate everything". There are other ways to handle those kinds of problems in today's Fedora (using multiple libraries with version numbers as part of the name as Weimer noted), but the Modularity effort will provide an easier way to do that.

The conversation is still ongoing as of this writing and no real conclusions have been drawn. The Fedora project, and its leader in particular, are looking toward a future where distributions do their jobs in a different way than they do today. It is not so much that the role that a distribution project plays is changing, but that the way it goes about it is. As Miller put it: "It is entirely about how we can better deliver the universe of free and open source software." That has always been a distribution's job, but the way to do so seems different these days and Fedora is doing its best to keep up.