RPM Community Forums

Mailing List Message of <rpm-lsb>

Re: LSB Package API

From: Denis Washington <dwashington@gmx.net>
Date: Sat 21 Jun 2008 - 16:32:53 CEST
Message-Id: <1214058773.5778.87.camel@dwashington>
On Sat, 2008-06-21 at 09:55 -0400, Jeff Johnson wrote:
> 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.

Thanks for taking a look. I am really new to programming RPM, so any
help is greatly appreciated.

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

I already figured that I might not have added all mandatory metadata to
the header. Unfortunately, I didn't find any documentation on which data
must be present. Can you point me at the right direction?

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

OK. Again, I didn't find any documentation on this, so I just filled
both. Which of them is preferred?

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

I don't know what you mean here. I use a separate transaction set for
_register_package() and _close_package(), closing after each function.

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

Yeah, I should probably verify that I got the right package in
_close_package(). Note that when _register_package() is finished, there
are no files installed yet, only stub files; that's why we can only add
the files' sizes in _close_package(), after the installer has copied the
"real" files over. RPMTAG_SIZE could be set to 0 in _register_package(),
though.

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

That's why both _register_package() and _close_package() close the DB
when there finished. The database is just open for while those two
functions are running.

> There are two calls to
>      rpmdbSetIteratorModified(iter, 1);
> one of the calls is unnecessary.

Oh, right. Oops.

> I also strongly encourage you _NOT_ to incrementally add tags to a
> header with a lazy rewrite into an rpmdb using  
> rpmdbSetIteratorModified().

What is the better way?

Regards,
Denis

P.S.: For follow-ups of general interest, I recommend you to reply on packaging@lists.linux-foundation.org. You can subscribe here:

  https://lists.linux-foundation.org/mailman/listinfo/packaging
Received on Sat Jun 21 16:33:02 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.