[lsb-discuss] Fwd: [packaging] A new take on Berlin: Announcing the Psys Library

Denis Washington dwashington at gmx.net
Tue Jun 15 08:44:32 PDT 2010

(Forwarded from the LSB packaging list (see address at the bottom); 
please write replies there.)


You may remember me. Back in 2008, when there was some talk about Ian
Murdock's idea of an LSB packaging API [1], I presented a basic sample
design and implementation of this concept, dubbed the "Burgdorf
Packaging API" (Burgdorf being my beautiful little home town) [2][3].
Unfortunately, while the discussion started by this was very
interesting, ultimately nothing really came out of it. Eventually my
focus shifted to other things (mainly "real-life"), so I stopped
developing my sample implementation and being involved in the discussions.

Recently, I found the time again to concern myself with the topic again.

There was a lot of criticism about the Burgdorf Packaging API proposal
after I announced it. Some were skeptical of the general idea of an API
for third-party software installers. I still believe that this is a good
first step, however, and while it won't magically solve all
cross-distribution Linux software deployment problems of the world, we
would have a good foundation to build upon if such a programming
interface would be available on any LSB-conforming Linux system.

I do agree on many technical issues pointed out, though. The D-BUS-based
client-server approach I used, while offering language independence and
the theoretical possibility on non-root installations, was somewhat
overly complex; a simple C shared library implementation would have been
much simpler and would have offered the same kind of easy bindability to
other languages (how many real-world language implementations don't have
a C bridge?). Similarly, the package manifest format could have been
substantially simpler; if XML has been the right choice as a base format
is highly questionable to say the least. The proposal also had some
rather big holes; for instance, the issue of version comparison (and
update in general) has not been addressed at all, neither package
uninstallation. Most importantly, though, the Burgdorf proposal requires
distro support from the start; there is no transition path for today's
distros, so even in the unlikely case that the API would be implemented
in the next version of every major distro (unlikely), it would take
years until it could be halfway be relied upon by ISVs (until it would
become part of the LSB, even), so in practice, the API would be
irrelevant and seldom used.

I realized that these are all rather major problems. So, I thought, why
not just try to sit down and implement something better?

As a result, I am very pleased to announce the completion of a
completely new proposal to you today: the Package Management System
(PSys) Library. As a general description, I'm citing the introduction in
the README or the project page [4]:

"The psys library provides a simple interface to the system package
manager of a Linux system. It allows installation programs to notify the
package manager of the installation, uninstallation and update of
third-party software packages, and to request these packages to be added
to or removed from the system package database. The psys library
interface is generic and not tied to a specific package management
system or Linux distribution.

Note that the psys library is only useful for adding and removing
software which complies to the Linux Standard Base (LSB) specifications.
Most notably, it is assumed that the data files of a software package
are installed into /opt as demanded by the Filesystem Hierarchy Standard
(FHS), and that a package only depends on the interfaces and
behaviorspecified by the LSB; any additional dependencies must be
contained within the package itself.

The psys library interface is meant as a proposal for a future version
of the LSB standard."

As you have certainly gathered, this is still the same concept as the
Berlin Packaging API. How does it differ from my last proposal?

* I tried to go more KISS as much as possible. The API is now just a
simple C interface. I have tried to document every aspect of the public
interface as detailed as possible; the documentation is available as
part of the psys library distribution in man page format (very UNIXy,
isn't that?), or online [4].

* Likewise, the implementation itself is simply a shared library. Well,
actually it's two: the implementation retains a frontend/backend split
as the "daemon" part of the Burgdorf implementation. The frontend,
"libpsys", implements all distro-independent functions; the distro- (or
package-manager-)dependent part is implemented in the backend, named
"libpsys_impl". This is either provided by the distro, or by a fallback
implementation which is included within the psys library itself. The
fallback backends give the implementation the cool property that it
could be used now, with today's (or even yesterday's) distros, to
archieve basic distro integration until the distros themselves would
implement more sophisticated psys backends. Currently, a basic fallback
backend for RPM-based distributions is provided.

* There is no package manifest format anymore. Instead, metadata is
simply provided by storing it in data structures defined by the API.
Code to serialize any "manifest format" to these data structures is
easily written, so this arrangement has the advantage of not tying the
programming interface to a specific metadata representation format (like
the Burgorf proposal does). It's all in the API. ;)

* The format of a version and the accompanying version comparison scheme
are now completely specified. Both have been carefully chosen to
(hopefully) only include the cases which are handled consistenly among
most package managers. (Most specifically, I have tried to take care
that the comparison algorithm yields the same comparison results as both
RPM and DPKG with versions of the allowed format.)

* There are functions for updating and removing packages from the
package database.

In its current state, the psys library is pretty basic, but already in a
usable state for RPM-based distributions. You can get the latest source
code from the project page on Gitorious [4]. If you have RPM installed
(it is also in e.g. the Debian/Ubuntu repos), you can test it by
installing the psys library with

      ./configure --enable-fallback
      [sudo] make install

and trying out the simple example installation, update and
uninstallation programs in the examples/ sub-directory. See the README
for more details.

Please also have a look at the library documentation, especially the
psys(7) man page which gives a general overview of the whole thing [6].
Criticism concerning the library interface is very appreciated!

So, this is it for now. I hope I can reignite the LSB packaging
discussion yet again with this proposal, and maybe, we can get some
results out of it this time around. I'll keep my fingers crossed.

Best regards,
Denis Washington

[1] http://www.linuxfoundation.org/en/Berlin_Packaging_API
[2] Mailing list thread:
[3] Documentation: http://www.linuxfoundation.org/en/Burgdorf_Packaging_API
[4] http://gitorious.org/libpsys
[5] http://gitorious.org/libpsys/pages/ManPages
[5] http://gitorious.org/libpsys/pages/Psys
packaging mailing list
packaging at lists.linux-foundation.org

More information about the lsb-discuss mailing list