FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 06-18-2010, 08:19 AM
Denis Washington
 
Default 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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4C1B2C1C.9010602@gmx.net">http://lists.debian.org/4C1B2C1C.9010602@gmx.net
 
Old 06-22-2010, 12:08 PM
Guillem Jover
 
Default Announcment: The Psys Library

Hi!

On Fri, 2010-06-18 at 10:19:40 +0200, Denis Washington wrote:
> 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.

I've skimmed over the blog posts and the discussion in the LSB packaging
mailing list, and it's still not clear to me why ISV would use a
library only supported on LSB systems, while they would not use an
LSB package (which supposedly only needs to be built once, and not
per distribution).

Generally, software packaged outside specific distributions tends
to be of lower quality, and lacks the integration provided by them, the
packaging fragmentation it produces is also a problem. I don't think
this is an actual problem for free software projects wanting to deliver
their software widely, as the ideal solution for those projects is to
just get their software packaged natively.

This seems to be targetted mostly for non-free software projects and
vendors, and also mostly for Linux (by way of the LSB, even if in
general it's actually a quite portable spec), so (at least to me) it
does not look like very appealing target group. And accordingly the
solution seems to be pretty narrow.

> 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.

libdpkg still needs major cleanups before it can be deemed usable by the
general public, it's exposed right now as a static library for the cases
where projects really need to link against it and would either bundle it
or build it separatelly anyway, with the accepted understanding of the
volatile nature of the API/ABI. The database handling code in dpkg is
separated into package metadata and file metadata, the former is
currently handled by libdpkg, the latter by dpkg itself. So currently
there's no way to access the latter only with the library.

“Registering” a package into the package metadata db, w/o going through
the dpkg program logic, will currently produce a somewhat broken
installation, and it will not be able to check for file conflicts. The
text db is to be considered an internal implementation detail, so
mangling it directly should not be considered a supported interface for
other programs (obviously admins can do with their system as they
please).

> * 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 guess I just don't quite like the general idea of third party
installers bundled with the applications, it just seems a recipe for
disaster, and also seems to go against what distributions are trying
to accomplish. System integration.

The fact that the third party installers would bypass dpkg so as to
install the files themselves, and then notify dpkg of what they did,
w/o properly integrating with things like local diversions, file stat
overrides, etc, or the possibility of writing outside of /opt anyway
and not notify libpsys, seems to make it a bit worse.

Currently the packaging architecture is layed out in a way were dpkg is
the only entry point when installing packages (.deb files). And lots of
checks are performed there. Even if the code can be reestructured to
accomodate libpsys, I don't think that diverging from the entry point of
a physical package file (be it a .deb or a LSB .rpm) is desirable.

In any case given the specificness of it, I don't see this API being
integrated in dpkg proper, if someone would want such backend in Debian
(even if I'd rather not) they could package it as part of psys itself.

> 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.

I'd rather see a neutral and universal package format (even if it
could start with a simple subset of what's needed), that could be
comfortably adopted by several free operating systems, and their
current native systems, but maybe that's just me.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100622120815.GA11688@gaara.hadrons.org">http://lists.debian.org/20100622120815.GA11688@gaara.hadrons.org
 

Thread Tools




All times are GMT. The time now is 06:02 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org