On Jun 21, 2008, at 5:15 AM, Denis Washington wrote:
Hi,
Some time ago, it was discussed on an LSB face-to-face meeting that an
API should be developed that allows ISVs to install sotware packages
which integrate into the package manager - the "Berlin Packaging API".
While the idea seemed to be well received, there didn't seem much
progress since then, except for a wiki page with a rundimentary
proposal
[1]. Considering that third-party software installation is an
undeniably
important weak spot of the Linux infrastructure, I found this was a
shame.
To reignite the the initiative, I decided to design and develop a
prototype implementation of the Berlin API, most creatively named the
"LSB Package API". It is designed as a simple D-Bus interface
accompanied with an XML-based package description format. A detailed
description and the source code can be found on this page:
http://www.linuxfoundation.org/en/LSB_Package_API
The implementation currently supports integration into RPM and
dpkg; due
to its modular nature, support for more package managers could be
added
later on.
I hope this implementation will act as a starting point for
resurrecting
the Berlin API process. Let us overcome the "Third-party software
installation on Linux sucks" problem and strive to a brave new
world of
easily distributable Linux software! ;)
As promised, here's certain issues I see in the current implementation.
In general, what is being called a Header does not include sufficient
metadata to be casually installed in an rpmdb. You can/will create
cause existing rpm deployments to segfault if you proceed with
the header as constructed in this implementation.
Look closely at the "LSB Packaging" documentation that describes
tag content, paying particular attention to the content that LSB has
chosen to call "MANDATORY". The fact that the header is in a rpmdb
rather than a *.rpm package does not permit MANDATORY to be ignored.
Adding both RPMTAG_FILENAMES and RPMTAG_{DIRNAMES,BASENAMES,DIRINDEXES}
is just wrong. One or the other should be done, not both.
The transaction set (and the underlying configuration/rpmdb handling)
cannot be scoped within the individual methods if you are going
to compute and add RPMTAG_SIZE lazily in _close_package().
A package header can change in an rpmdb between method
calls, and keeping the rpmdb open (or alternatively, verifying that
the header retrieved is the one that should be modified). I see
no reason why RPMTAG_SIZE needs to be added in _close_package().
(aside) There will be other DoS issues that you will encounter if you
try
to keep an rpmdb (or any database) open persistently in a daemon.
There are two calls to
rpmdbSetIteratorModified(iter, 1);
one of the calls is unnecessary.
I also strongly encourage you _NOT_ to incrementally add tags to a
header with a lazy rewrite into an rpmdb using
rpmdbSetIteratorModified().
hth
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
LSB Communication List rpm-lsb@rpm5.org
