[packaging] first steps toward a packaging API
imurdock at imurdock.com
Thu Jan 25 05:36:08 PST 2007
All right. I've previously posted a few links which are relevant to the
task at hand here:
* http://ianmurdock.com/?p=388 ("Software installation on Linux: Today, it
sucks (part 1)")
* http://ianmurdock.com/?p=391 ("Software installation on Linux: Tomorrow,
it won't (with some cooperation) (part 2)")
* http://www.linux.com/article.pl?sid=07/01/10/2045258 ("Linux Standard
Base plans cross-format package API")
To summarize the main points:
* Software installation on Linux sucks today.
* We at the LSB want to help make it not suck.
* ISVs want to treat Linux as a single platform--in other words, they
want to create a single package for Linux, much as they do for Windows,
rather than having to make different packages for each Linux variant.
* The LSB is a huge step toward this end goal, but it's not enough--there
has to be an easy way to package up LSB compliant binaries and deliver
them to end users. In other words, whereas the LSB today makes it easy
to create portable executables, what we really want are portable *apps*.
* The distributions are hugely invested in their existing package
systems. Radical departures from where we are today are non-starters.
Whatever we come up with must work with existing package systems,
most importantly RPM and dpkg.
* ISVs are hugely invested in their existing software installation
mechanisms. Radical departures from where we are today are non-starters.
Neither are Linux-specific solutions. Case in point: ISVs aren't even
interested in supporting RPM in most cases today. Whatever we come up
with must work with existing software delivery mechanisms, which
means the vendor maintained install scripts and cross-platform
installation frameworks (e.g., InstallAnywhere) ISVs already use.
* Current solutions ISVs employ today (install scripts, InstallAnywhere,
etc.) integrate poorly if at all with the distribution package systems.
In most if not all cases, files are simply placed in the file system, and
the package system is not even aware of them. This can cause
conflicts between distribution packaged software and third party software,
and additionally makes it difficult or impossible to manage third party
software using system management solutions based on the packaging systems.
* Basically, what we need is a way to bridge the gap between what the
distros provide today (the package systems) and what ISVs want. In short,
we want an API that can be implemented across the package systems (RPM,
dpkg, etc.) that will allow the install scripts and frameworks to
communicate with those package system (e.g., "I just installed a file
here, and I'm called XYZ"). This way, ISVs can continue to use
their current software installation mechanisms, and the packaging systems
(and the system management tools built atop them) will have
the information they need to be able to manipulate/manage them as needed.
* Our goal should be build the smallest, simplest API possible,
because the smaller and simpler it is, the more likely it is
to get implemented in the major distros. And it's not useful to
anyone until it's in all the major distros.
* The key to making this work is having the right people at the table.
Fortunately, we had all the right people at the Berlin meeting,
including key packaging people from Debian, Red Hat, SUSE, and Ubuntu.
They're all here now too.
Given that, let's start small and build it up. And let's not get ahead of
ourselves. Thinking big is good, but let's concentrate on the small steps
At the Berlin meeting, we outlined a few key requirements for the API:
* There needs to be a way to query the system to determine whether
it is LSB compliant, and if it is, what version it is compliant with.
LSB compliance is important because it eliminates our need for
complex dependency management, i.e., most applications will simply
have a single dependency:"LSB (>= x.y)", where x.y is the version they are
compliant with, and ">=" works because of the backward compatibility
* There needs to be a way to register with the system to let the system
know that a new component has been installed. This is important so that
the package system can see and potentially manipulate third party
software. (Naturally, if we have a register, we need an unregister too.)
* There also needs to be a way to provide VERY BASIC metadata about the
component being installed, e.g., which files it has placed where. This
doesn't need to be a full mapping of the metadata RPM and dpkg
maintain, just the stuff third party apps require. It was suggested that
an XML manifest designed for the repo metadata project could
be used. I don't remember the details here--Seth, perhaps you can expand?
* There needs to be a VERY BASIC dependency mechanism. This is important
because the LSB is designed to be extended, and we want to make it possible
for applications to take advantage of extensions in a formalized way.
Namespace collisions are eliminated by the LANANA registration requirement.
For example, an LSB compliant MySQL might extend the LSB to provide an LSB
compliant libmysqlclient that is portable across distros that other LSB
compliant applications may use. Currently, there are incompatibilities
between different distro-provided libmysqlclient packages, so it would be
very difficult for an LSB compliant application to interface with MySQL
without a mechanism such as this (this example comes directly from MySQL).
And... that's pretty much it. Anything I've forgotten, anyone else who
was there? Anything to add, those of you who weren't?
More information about the packaging