RPM Community Forums

Mailing List Message of <rpm-lsb>

Re: LSB Package API

From: Jeff Johnson <n3npq@mac.com>
Date: Sat 21 Jun 2008 - 15:55:48 CEST
Message-id: <EED324C5-D772-4F7F-8A7D-9B4486A38DCB@mac.com>

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
Received on Sat Jun 21 15:59:55 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.