Announcment: The Psys Library
Hello,
I would like to announce a project to you which aims to attack the
problem of cross-distribution, but distribution-integrated, Linux
software deployment, and might interest you. It is a simple library
written in C, called the "psys library" ("psys" standing for "package
management system"). From the README:
"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 [1]. 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)
[2], and that a package only depends on the interfaces and behavior
specified by the LSB; any additional dependencies must be contained within
the package itself.
The psys library interface is meant to be a proposal for a future version
of the LSB standard."
Those who remember will notice that this is the same idea as the "Berlin
Packaging API" proposal discussed on an LSB Packaging Summit as part of
the LSB face-to-face meeting 2006 in Berlin. The aim was to bridge the
gap between ISVs on the one hand, many of which have invested in
cross-platform installers and would like to use those on Linux too
(instead of having to make not only one, but mulitple additional
packages in various formats for Linux deployment), and distributors,
which would like all software to be centrally managed by their package
manager of choice. By giving installers a way to communicate with the
package manager through a simple, LSB-standardized library interface,
both sides would benefit: ISVs could use their installer frameworks with
only few changes, and distributors would gain control over software
installed by such installers, integrating it into their package
database. There seemed to be a general agreement at that time that this
would be the right approach to go forward. For more details about what
was discussed and why, see the two-part blog post on this matter by Ian
Murdock (who attended the summit) [1].
Unfortunately, nothing really came out of that. No proof-of-concept
sample implementation was created, leaving the whole concept kind of in
a vaporware state. In 2008, I attempted to change that with a concrete
design and implementation which I named the "Burgdorf Packaging API"
[2]. Unfortunately, it was somewhat over-engineered (using technologies
such as D-BUS, PolicyKit and XML) and would probably have required a too
big amount of code changes to installers; and while it spawned some
discussion (including the thread following my initial announcement on
the LSB packaging mailing list [3], a blog post by PackageKit creator
Richard Hughes [4] and a short OSNews article [5]), the outcome was,
again, nothing.
So now, two years later, I am trying again with the psys library. The
concept stays the same, but the library is much simpler in design and
implementation than Burgdorf. It is now just a simple C function
interface; the complex XML-based metadata format has been replaced by
programmatic definition of the metadata; and adopting installers to use
the API should generally be much less work.
The psys library is not just an idea or general design. There is a
complete implementation, and I have tried my best to document the
library interface as throroughly as possible. The source code and
documentation can be found at the project's page on Gitorious [6].
The library implementation is split into a frontend and a backend part.
The frontend is distribution-independent; it is implemented in the psys
library source code itself. The backend, on the other hand, is thought
to be provided by the distribution (or package manager); it does the
hard work of ensuring that an installation attempted by an installer is
sane (overwrites no files, does not conflict with installed packages
etc) and of adding packages "registered" by an installer to the system's
package database. The core psys library also supports the concept of
"fallback backends", which can be used if the distribution does not
support psys. These fallbacks allow the psys library to be used *now*,
with no distribution-side changes, by linking it into the installer -
this would allow a smooth transition period until the interface is
supported by distributions directly. Currently, the psys library comes
with a fallback backend for RPM-based distributions (tested successfully
on Fedora 13 and openSUSE 11.2).
I am naturally not writing all this to you without reason. I would like
to ask you for help.
* I am currently investigating the implementation of a DPKG fallback
backend to complement the RPM one, but I'm not sure which implementation
strategy to use. I have noticed that the DPKG database seems to consist
of only flat text files, but editing them directly would probably be all
too flaky and bug-prone, though. I also found out about a library named
libdpkg which would do what I need (it seems to be the core of the
actual dpkg codebase, is that correct?) but it doesn't seem to be
available in Debian version prior to squeeze, and I don't know if just
statically linking that in would be a solution to use the backend in
pre-squeeze Debians. Is somebody interested in helping me with this? I
would be very thankful for any pointer or helping hand.
* I would like to know what you think about the psys library and the
concept behind it in general. Could you imagine supporting such an
interface in dpkg? Or do you think the idea is fundamentally flawed, and
that dpkg should not support cross-distro installers in this way?
I am very interested in your feedback and hope you can help me to make
the vision of easy cross-distribution software deployment on Linux a
reality.
Best regards,
Denis Washington
History:
[1]
http://ianmurdock.com/linux/software-installation-on-linux-today-it-sucks-part-1/
[2] http://www.linuxfoundation.org/en/Burgdorf_Packaging_API
[3]
https://lists.linux-foundation.org/pipermail/packaging/2008-June/000732.html
[4] http://blogs.gnome.org/hughsie/2008/06/24/lsb-package-api/
[5] http://www.osnews.com/story/19901
Psys Library:
[6] http://gitorious.org/libpsys
Reply to: