Linux.com

Feature: Linux

Linux Standard Base plans cross-format package API

By Bruce Byfield on January 17, 2007 (8:00:00 AM)

Share    Print    Comments   

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.

Bruce Byfield is a computer journalist who writes regularly for Linux.com.

Share    Print    Comments   

Comments

on Linux Standard Base plans cross-format package API

Note: Comments are owned by the poster. We are not responsible for their content.

sounds great !

Posted by: Anonymous Coward on January 18, 2007 01:57 AM
It would solve 50% of the problems for newcomers to Linux who are baffled by RPMs, repositories, and dependencies; and it will save time for developers

#

I hope we don't end up like the Windows peasants

Posted by: Anonymous Coward on January 18, 2007 02:32 AM
who are at the mercy of every third-party installer that comes down the pipe. Sure it's "one click to install" but it's a Faustian bargain: you've given a big slice of your computer completely over to Norton or Adobe or Apple or the Ukranian Mafia, or worse yet, Microsoft. "And we're givin' it to ya for free, so shuddup and eat yer spyware, er, updates."

I've had all of that plate I care for, thank you.

#

Re:I hope we don't end up like the Windows peasant

Posted by: Anonymous Coward on January 18, 2007 03:49 AM
That is why you should be able to extract packages without installing them. Then you can look at it, and scan it, etc.

That is why packages should be able to be digitally signed.

That is why packages should contain metadata about licenses, so you are sure to only install software with FSF-approved and OSI-compliant software licenses.

#

You Are A Tard

Posted by: Anonymous Coward on January 18, 2007 06:19 AM
You can extract Windows and RPM packages without installing them.
You can look at the files and scan(assume you mean virus scan) the files.
Many packages both Windows and RPM are digitally signed.
Windows and RPM packages can contain all sorts of meta data including license agreements and click through EULAs, dependency information and a lot more.

So, we already have the features that you describe in both Windows and Linux and yet package installation is a mess, especially in Linux. Furthermore, none of these features has prevented the installation of spyware enhanced packages on Windows. In fact many systems come with the spyware preinstalled by the manufacturer. Some people actually like tool bars from Yahoo! and Google despite the fact that they are indeed spyware! You are a tard.

#

Who's 'We' ?

Posted by: Anonymous Coward on January 18, 2007 07:07 PM
You should understand that you're not the only one using Linux. Nobody forces you to use any software coming with an installer, whether it be free software, freeware, spyware, or proprietary software.

On the other hand, there are people using Linux who have better things to do with their lives. They don't want to learn all the various ways to install software under Linux. It's such a waste of time, that they would probably also accept spyware build into regular free software -- just to get rid of the installation riddle.

Or do you *really* think it would be such a problem to set up a special APT repository full of ad- and spyware and talk people into using it? Maybe the software is really doing useful things? Stuff that the free software community has been unable to provide so far?

Talking about spyware, I know lots of free software guys who couldn't wait educating Google about their private eMail conversations.

Get a clue and stop spreading FUD, please.

#

Re:Who's 'We' ?

Posted by: Anonymous Coward on January 18, 2007 09:27 PM
Speaking as someone who survived windows spyware, I'd like to point out thats its perfectly easy to survive without downloadnig & installing spyware.

However when I came to Linux I came because I DIDN'T HAVE TO! I can download anything that looks good from the debian repositories safely without thinking "is this safe?", I wouldn't trade that for not having to learn how to install software, not in a million years. (And if you don't want to learn how to use a computer you deserve every virus and computer repair bill that ever comes you're way)

I'd also like to point out as easy as it is for you or me its impossibly hard for most people for some unexplainible reason. Therefor anyone building an installer should take into account that if they don't build a safe one then thousands of virus infections are on their hands. It would be criminally neglilent for the LSB to make system that lets users install programs in an unsafe way.

#

Re:I hope we don't end up like the Windows peasant

Posted by: Anonymous Coward on January 18, 2007 09:35 PM
I agree fully with what you said, I'd recomend you join the packageing mailing list (its public after all).

<a href="http://www.freestandards.org/en/Packaging" title="freestandards.org">http://www.freestandards.org/en/Packaging</a freestandards.org>

#

Re:I hope we don't end up like the Windows peasant

Posted by: Administrator on January 19, 2007 10:40 PM
Spyware has to declare itself in the license to be legal, and it does. It works because people don't read the license... Ever. Most people wouldn't know what to look for. Spyware is an invited guest. That's why I don't have any spyware on my Windows systems even though I don't dare install security software.

So really you don't need to do any nerd-sleuthing at all to see if there's spyware in there. It's all up front if you know where to look and what to look for.

The other thing is that spyware is market driven; it's only really a problem if enough people use Linux to justify producing it for Linux.

If Linux was a big enough market to warrant spyware development, we would already have it. So would the Macintosh.

If you're a good programmer and you get together with several other good programmers and don't have any qualms about spyware and there's a big financial opportunity, you can figure out how to infect Ubuntu or Fedora.

But you need many, many millions of non-techies to warrant it financially or else you're just wasting your time. That right there is what Windows has that gets the spyware.

If Linux had that, you could just as easily stick a spyware in an RPM, have the clueless user double-click it, the system asks the root password and we all know what happens next<nobr> <wbr></nobr>:)

#

My opinion

Posted by: Anonymous Coward on January 18, 2007 03:09 AM
It is very good that they have brought together big and important groups in the Linux community such as Red Hat, Mandriva, Novell, Debian and Ubuntu.

Getting a good cross-distribution package solution and bringing ISV's over are essential to the success for Linux on the desktop.

I think there should be a open standard file format which can be;
* Associated with an GUI software that opens the installer and lets you install the software. Think MSI.
* Installed from the command line using a CLI software.
* Installed using a package management application.
* Can be uninstalled via the command line or via a graphical central package management system application.
* Files can be extracted from the package without having to install the package.

The implemention of the cli/gui/package-management-system is up to anyone to code, and the user/distro can choose which of these software to run as long as they can handle the standardized package format.

The package should also be able to contain;
* Digital signature (optional).
* Metadata for name of software, version, license, url and dependency.

It is up to the developer of the software to decide whether his software should support dependency checking/resolution, hashes or metadata and other stuff. It is also up to him to decide in which programming language he want to code it in, and which libraries he want to use, etc.

#

Re:My opinion

Posted by: Anonymous Coward on January 18, 2007 06:38 AM
It is my opinion that you don't understand the problem, or know what you are talking about.

RPM and Debian apt package management systems already have all of the features that you describe. ALL of them! The problem is with the fact that they are two distinct and relatively incompatible systems and neither side is willing to cede to the other. This means that ISV's must produce multiple packages for their applications.

This guy thinks that his solution is best and will fix it all if everyone adopts it. It could indeed fix the problem but so could RPM or better yet, apt. All his idea will actually be is a third, make that fourth, option. The AutoPackage guys already decided that they were going to fix this problem but, true to form, none of the distros is interested in adopting it. The not-invented-here attitude is most prevailant in the Linux community. If you doubt that, just look at the number of MP3 players on SourceForge and then check FreshMeat to see how many of them are new this month.

#

Re:My opinion

Posted by: Anonymous Coward on January 18, 2007 09:12 AM
Because to get a package system widely adopted, you have to make sure you have some major distributions to back it up and be ready to adopt it.

With an open and standardized specification, the distributions don't have to use the same implementation, they could all have different software, but it all handles the same file format.

#

Re:My opinion

Posted by: Anonymous Coward on January 18, 2007 09:45 PM
The problem is not that there is RPM & dpkg, there's an easy, automatic, way of turning a<nobr> <wbr></nobr>.rpm into a<nobr> <wbr></nobr>.deb

The problem is tha there are diffrent file layouts and diffrnet libaries installed on each distro

#

Missing two points

Posted by: Anonymous Coward on January 20, 2007 07:20 AM
Two things:

1) If RPM and DEB have been in place for years and work well, why should they change? Calling this resistance "not-invented-here" forgets the point that Autopackage came *later*.

2) Why should they change to Autopackage and not SMART or Conary? From the last time I checked, Autopackage was "just another package manager" and it insists on installing (or worse, uninstalling) to the<nobr> <wbr></nobr>/usr directory even though that could mess up the native package management. SMART and Conary seemed to handle this better, and Conary at least addresses incremental updates better than either DEBs or RPMs (similar to Portage).

#

You didn't read the article

Posted by: Anonymous Coward on January 18, 2007 05:57 PM
Or maybe you just didn't understand it. We already have an "open standard file format", in fact we have more than one, which is the problem. Defining another one would just make the problem a little bit worse.

#

So what does all this mean?.

Posted by: Anonymous Coward on January 18, 2007 04:41 PM
I guess what he is saying, is that we should roll out a big "Welcome" mat to user subjugating software.

Thanks, but no thanks!.

#

Re:So what does all this mean?.

Posted by: Anonymous Coward on January 18, 2007 09:42 PM
Sadly I think you're right about Ian's Point of View. If you read his blog he seems to think that Linux is doomed "like UNIX" if we don't have a "third party software ecosystem", funny he thinks that when nearly any distro has more software than 90% of users ever want in the repositories.

If you disagree with Ian him I would sign up to the (public) LSB packagers mailing list and say you're viewpoint <a href="http://www.freestandards.org/en/Packaging" title="freestandards.org">http://www.freestandards.org/en/Packaging</a freestandards.org>

#

Small clarification

Posted by: Anonymous Coward on January 18, 2007 08:19 PM
In the article it says: "One possible solution is to encourage a new common package system for all distributions, such as autopackage."

This could be read as if Autopackage was created as a potential replacement for systems such as RPM and DEP. It wasn't. In the Autopackage FAQ, it says:"

# Is autopackage meant to replace RPM?

No. RPM is good at managing the core software of a distro. [...] What RPM is not good at is non-core packages, ie programs available from the net, from commercial vendors, magazine coverdisks and so on."

It's a joke that distributions will now get not only one additonal package format but -- due to API -- several of them. Every third-party application is going to use either its own installer or one of the other systems such as Autopackage, Klik or Bitrock.

And users are going to be really happy about the additional confusion. However, it will at least be reduced to understand that one needs to make any downloaded software package executable before it self-installs. Oh! Noticed something?

The Linux distributions decided to ignore user problems because they didn't want to give up control. It's a shame that they will probably blame installers in general if there'll be a mess. However, it's their own fault that they didn't establish a single (additional) system in time.

#

Re:Small clarification

Posted by: Anonymous Coward on January 18, 2007 11:04 PM
"However, it will at least be reduced to understand that one needs to make any downloaded software package executable before it self-installs. Oh! Noticed something?"

I think that sounds bad. Packages should not be executables, they should be in a file format with a file extension that is associated with an installer, just like<nobr> <wbr></nobr>.MSI

#

Integration with RPM

Posted by: Anonymous Coward on January 19, 2007 10:30 PM
The article is incorrect, BitRock InstallBuilder <a href="http://bitrock.com/" title="bitrock.com">http://bitrock.com/</a bitrock.com> supports registration with the underlying RPM database (.deb support is in the works). In fact, version 4.0 actually is able to generate standalone RPMs. It is also possible (though not automatic) to check for pre-existing RPM dependencies as well.


Our long term goal is to integrate as closely as possible with the underlying operating system, be it Linux, Solaris, Win, OS X or any of the other platforms we support. For example, we follow freedesktop.org standards whenever possible (desktop icons, etc)


Daniel

#

Protopackage

Posted by: Anonymous Coward on January 20, 2007 05:58 AM
From what I read the idea here is to make an api to be driven by the ISV.

I suggest a opposite. What the world needs is a protopackage. A packageformat that is designed to be transformed into a native format by distributors.

The design should focus on making the lives easier for distributors by letting them share all work that can be shared in the protopackage, and have good tool integration to import the package into their distributionchannels.

#

ebuilds

Posted by: Anonymous Coward on February 13, 2007 05:56 AM
Please dont forget the ebuilds.They are already
a standart of making packages (in gentoo world)
There has been mentioned we need some information about the package, what was on||off when compiled, what are the depencies and so on.
But the most important thing.There must be a way,
when you have a source code only to make "simply" a new package.And I am pretty sure that an ebuild is the best middle step between source and package. It is quite easy to write one and all necesary information are already there.
Please consider that.

#

This story has been archived. Comments can no longer be posted.


 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya