Structural impediments

Structural impediments

Posted Nov 7, 2006 14:02 UTC (Tue) by brugolsky (subscriber, #28)
Parent article: Big decisions loom for Fedora

Fedora has accumulated a number of structural impediments that make certain improvements difficult, and keeps the average sysadmin mired in operational issues, rather than incremental improvements to Fedora that can be pushed back upstream.

Top of the list, methinks, is RPM/yum. RPM provides five things: a pristine source + patches build technology, a container for bits, versioning, dependency management, and scriptlets that are triggered on install/update/removal.

When managing more than one host, or virtual machines on a host, RPM shows its weaknesses compared to Conary, or other potential solutions. As a Fedora user, I keep downloading the same bits, because the contents of the (N+1)th release of a package is often nearly identical to the Nth release -- especially if that package has "font," "langpack," or "i18n" in its name! RPM makes it unnecessarily difficult to maintain a set of hardlinked chrooted environments, or virtual disks, snapshots, etc., because it churns the filesystem. Because sharing an image is inordinately difficult, I have prelink turned off, so that identical packages installed on different hosts have identical files.

On the package building side, the spec file format suffers from all the traditional problems of poorly implemented macro languages and policy, and has discouraged abstraction and higher-level tools (such as the use of the various fedora-rpm* tools). Code is replicated hundreds of times, with slight variations (e.g. $RPM_BUILD_ROOT v. %{buildroot}, "make install" v. %makeinstall) all throughout the distro, rather than being centralized into recipes for GNOME apps, KDE apps, kernel modules, ... Packages are littered with scriptlets that only work in the forward direction, and there is no easy way to hook it to do otherwise, because all of the scriplets are open-coded.

Maintaining local versions of packages is a nightmare. Rather than being able to specify that I want my build to be the same as the upstream build, except that I want my locally-maintained path series applied, and different options to configure, instead I have to hand-edit the spec file every time I roll a package forward. On FC4, I have 95 locally built packages, most of which involved some hand-editing, some to apply patches (which have been rejected or dropped upstream, for whatever reason), others to fix up things like SELinux and XFree86/Xorg dependencies/build-options from Fedora development packages.

Another problem is network config. The initscripts that Fedora inherited from Red Hat Linux are more suitable to the BSD-like Linux-2.0 view of the world. Alexey Kuznetsov and others added a mind-boggling array of networking functionality starting with Linux-2.2 (circa Red Hat Linux 6.x timeframe), and it is largely useless in Fedora without lots of custom scripting. For the most part, the initscripts package does nothing useful with: secondary IP addresses, policy routing, packet marking and filtering, and traffic control and QoS. NetworkManager addresses some of these issues for wireless users, but various important pieces are missing. The /etc/net framework provides an improved static configuration, but there is as yet no dynamic network management framework that would provide the simple interface of a Cisco router, despite the Linux kernel being more featureful than Cisco IOS in many regards. [Quagga offers a limited subset of Cisco CLI functionality, but because it is cross-platform, does not solve the whole problem of interface and link management, etc. The commercial version of Zebra in ZebOS includes some of the desired functionality.]

Also on my hit list is the sorry state of LVM snapshotting. Things have only stabilized in the last six months, and the current snapshot implementation is very slow and only suitable for taking backups. Running with multiple snapshots brings a fast block device to a crawl. The wandering log technology in Reiser4 is interesting from an in-filesystem snapshot perspective, but that appears to be going nowhere fast. One can only hope that something suitable will find its way into Ext4.

I am hopeful that the intense interest in virtualization, as well as the needs of OLPC will spur Red Hat and the Fedora Project to address the need to make Fedora easily configured and managed, and readily branched for development, customization, or isolation.

---

to post comments