Working towards a cross-format package API

What was known as the Free Standards Group (now the newly formed Linux Foundation) announced plans to introduce an API which ties together major package systems and software installers within the next version of the Linux Standard Base (LSB). The goal is to simplify the prospect of writing software for Linux from the ISV perspective. The proposed LSB API is to serve as standardized point-of-entry to the underlying platform for software which is independent of a distribution's package management repository. At this point in time, version 3.1 of the LSB doesn't provide much assistance or clarification regarding this issue outside of more or less declaring RPM as the standard format.

I would hope this initiative stays near the top of the Linux Foundation's agenda in the coming year in spite of what will be an ongoing organizational restructuring process. Some have labeled these plans as 'band-aid fixes' which are used instead of working to standardize on a new package management system. This line of thought sounds great until you come to grips with the numerous impracticalities of not only formalizing that standard but also enforcing it across a fiercely independent and globally dispersed Linux community. An API approach that can be used by ISV's as well as third party management systems has the best chance of thriving amongst the varied Linux factions. Whether it takes hold right away or not is an entirely different subject, but it begs to be investigated and put into motion.

Maybe I'm a tad bit biased, but I really see a solid API as one of the foundations for establishing the Linux desktop as an open platform for innovation. Right now some really cool things are going on within different distro communities as well as amongst a growing third party Linux software ecosystem. The timing is right to introduce this type of initiative which can help tie those efforts together in addition to further opening up the playing field to other players. Granted, an API isn't the magic pill which will necessarily push Linux 'over the top' but it is another step in the right direction.

Some keys for this effort will be:

Integrating input from a wider variety of qualified sources.

Ensuring an initial set of solid specs which can serve as a baseline.

Getting those specs included with LSB 4.0

Establishing strong outreach initiatives to educate/inform.

Additionally I'm interested in how the OSDL+ FSG = Linux Foundation equation is going to effect the governance of the API as well as its timeline. Although it's highly probable that it will fit in well with the new organization's agenda. I personally favor the idea of a slimmed down, foundation approach a la Apache and Eclipse helping to narrow the gap between closed platforms and Linux. And hopefully, the LSB API doesn't get lost in the restructuring shuffle.

Comments

Hi Alex,

Getting the vendors to agree on a 'standard' while getting ISVs to trust that the API will work just as well as today’s method (write/test differently for the distros you want to run on) and will work in the future (i.e. a leading vendor won't go their own way) is going to be a challenge.

I'd be interested to know how many ISVs test directly against the LSB and not against RHEL or SLES individually. One could argue that having the LSB means ISVs can test one LSB-certified platform thoroughly and then just run distro-specific tests (GUI, install, etc) on other LSB-certified platforms. In any case, the LSB-related metrics may give us an indication of the uptake that the package API could expect.