January 17, 2007

Linux Standard Base plans cross-format package API

Author: Bruce Byfield

For independent software vendors (ISV), one of the major problems in supporting GNU/Linux is the variety of package management systems. However, if the Free Standards Group has its way, the next version of the Linux Standard Base (LSB) will solve that problem by providing an application programming interface (API) that acts as a bridge between the major package systems and software installers. Ian Murdock, CTO of the Free Standards Group, says the solution could be included in the most widely used distributions by early 2008.

Murdock notes that, from an end user's viewpoint, software installation in GNU/Linux distributions has improved considerably in the last few years. In particular, he points out that, with dpkg and yum, automatic dependency resolution has become the norm.

However, for ISVs, problems remain. "There's a real divide," Murdock says, "between what the Linux distributions provide and what's available for third-party software. Most of these companies are supporting Linux as the second or maybe third platform. They're already dealing with a multitude of packaging systems. The last thing they want to hear when they're porting their software to Linux is that they have to support yet another package system. Not only that, but it's a very low-level package format."

What ISVs need, Murdock suggests, "is a way to find whether the underlying platform provides all the functionality that their applications use. And they need to be able to tell the package system what they're doing. They're in this third-party software ecosystem which is outside the repositories that a distribution's package management provides. And once you move outside the repositories, things start to fall apart pretty quickly."

Currently, no satisfactory solution exists for this problem. Applications like Install Anywhere and BitRock Builder provide installers comparable to those found on Windows, but, as Murdock points out, "They don't integrate well with the package systems. The result is like a tarball, except easier to use." The installers produced by such applications can neither check dependencies nor register installed programs with the package management system. Nor do they provide application management across a heterogeneous network, because administrative tools tend to be specific to a specific package system.

Murdock notes that the latest version of the LSB provides no assistance. Chapter 22 of the Linux Standard Base Core Specification 3.1 specifies RPM as the standard format, "but it really doesn't go beyond the RPMs of maybe five years ago" -- that is, before yum provided dependency resolution. Nor is any provision made for other package systems, although Murdock notes that Debian-based systems can use the alien command to install or convert RPMs that meet LSB specifications.

Looking for a solution

One possible solution is to encourage a new common package system for all distributions, such as autopackage. However, Murdock firmly rejects promoting a new system. "That's where you're basically trying to convince people to throw out existing investment," he says. "That's not viable."

Even Mike Hearn, one of the original developers of Autopackage, an alternative packaging system, has to agree. "Waiting for the distros to get on board is a waiting game that can never be won," Hearn says. "They are too set in their ways."

Instead, at the recent Packaging Summit held in Berlin in early December, Murdock promoted the idea of developing an API that will act as a intermediary between a distribution's package system and third-party software.

Murdock finds the closest existing analogy to the API in Real Network's installation script, which identifies the packaging system, and then installs the files for RealPlayer to the appropriate locations. "What the standard will do is enable the installer at specific points in the script to call out to the package system," Murdock says. "Instead of having to have specific knowledge about specific distributions, ISVs can simply rely on the LSB and the interfaces that the LSB will have present." All that ISVs will need to know is whether a distribution is LSB compliant or not.

"The API will be available to anyone like RealNetworks who write their own installation script," Murdock says. "We're hoping that Bitrock, klik, autopackage -- any of the third-party management systems could utilize the API as well."

Building the solution

The recent packaging summit was attended by representatives of the major distributions that use the two main packaging formats, with RPM represented by Red Hat, Mandriva, and Novell, and dpkg by Debian and Ubuntu. Murdock considers this attendance an encouraging sign. "If anything, the distributions are encouraged that we are taking this very simple, pragmatic approach."

Murdock views the participation of as many distributions as possible as essential to the development and acceptance of the API. "The real trick is not how long it takes to build the standard," he says. "The hard part of building a standard is getting the right people at the table -- those who are in a position to make that standard actionable. You can sit around all day and agree that there should be a standard, you can even agree what the standard will look like, but if you don't have buy-in and participation from the people who can actually implement it and get the standard to be widely used, then you're wasting your time."

Given that representatives of the major distributions were party to the decision to build the API, Murdock may already have the buy-in that he believes the initiative needs. "We support the idea," says Michael Vogt, who attended the summit on behalf of Ubuntu. Bruce Lowry, director of global public relations at Novell, says simply, "We support LSB standardization efforts across the board. We do believe that the concept of an API to allow third-party installers to interface with native package management systems is, in fact, easier than trying to develop a new standard." Similarly, Fedora Project Leader Max Spevack, who is also a Red Hat employee, says, "It seems like a good way to go -- an API that can work on top of existing packaging systems seems more plausible than trying to create a new packaging system from scratch."

However, the idea may be a harder sell in the community. No public discussion of the idea seems to have occurred in Debian, the distribution most likely to provide a exhaustive critique (and, of course, the one that Murdock founded). Even more importantly, while some comments on Murdock's blog entries on the subject are favorable, or supportive largely because of Murdock's reputation, at least half are skeptical. Some question the need for improvement, or why GNU/Linux should make things easier for ISVs, who many equate with proprietary developers. Others point out that the Windows platform is not as monolithic or as convenient for installations as Murdock implies, and the problem with GNU/Linux is not just different package systems, but different system architectures as well. In fact, some suggest that the current package systems are already sophisticated enough, and ISVs simply need to educate themselves about them.

Other comments raise concerns about potential security problems, such as a lack of feedback from third-party installers about the changes made to the system, and the possibility of files being overwritten by a badly designed installer.

Murdock himself acknowledges another problem: the fact that only the major package systems were represented at the summit. However, he hopes to see broader participation as the project gets underway. "If Gentoo or anyone else wants to get involved in this right now, they're more than welcome," he says. "I encourage anyone who is reading this piece who's interested in packaging to go to www.freestandards.org, click on the Workgroups tab, and scroll down to the packaging link."

Setting the time line

According to Murdock, the API currently exists as only "a very basic outline of the kind of functionality that the standard is going to need to provide. What we're going to do over the next six months or so is actually hammer out these specifications."

Once the specifications are finalized, Murdock hopes that the API will become part of version 4.0 of the LSB, and be widely implemented in "a year, a year and a half from now." Around that time, he hopes that the next releases of Red Hat Enterprise Linux and SUSE Enterprise will be out, and the Debian-based distributions will have completed their rewriting of dpkg.

At that point, Murdock says, "we can go to the ISVs and say, 'This standard is now ubiquitous. You can rely on it being there.'"

Until then, however, Murdock and the LSB will be engaged in diplomacy with the distributions as much as writing specifications or code. "It's sort of a well-coordinated dance," he concludes.

Bruce Byfield is a computer journalist who writes regularly for NewsForge, Linux.com, and IT Manager's Journal.


  • Linux
Click Here!