Re: 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
Reply to: