LSB Package API

[Richard Hughes]

On Sun, 2008-06-22 at 20:02 +0200, Denis Washington wrote:
> We shouldn't resignate just because nothing came out of the previous
> attempts. Also, the LSB Package API is designed to require as little
> adjustments as possible to installers - it's just to calls and a single
> file, after all.

Uses a DBUS service: check
Uses pluggable backends: check
Use PolicyKit: check
Use an XML parser: check
System activation: check
Define own linked list implementation: check

> As already mentioned before in this thread, the focus of PackageKit and the
> LSB Package API are quite different, so there is no big reason for them to
> not exist side-by-side.

Err, http://www.linuxfoundation.org/en/LSB_Package_API suggests
otherwise.

You've got calls to PolicyKit, a system activated daemon, pluggable
backends - you might as well call the project LSBPackageKit. You don't
appear to have any defined scope for the project and it seems to be just
be technology-bingo at the moment.

> I don't think this is a corner case at all. For one thing, propietary
> applications might just don't play a role _because_ there is no really
> good distribution method for them - the typical chicken-and-egg problem.
> (I'm not saying this is the only reason, but an important one.) We're
> just not giving them an easy method of cross-distro integration. I think
> providing this is important.

Have you talked to customers? I have. Lots of them. Customers don't want
DBUS services or PolicyKit, they want one of two things:

1. A tested (supported) binary package for something like RHEL and SLED.
2. An installer that uses something like /bin/sh for the other distros.

If you want them to use a library to install stuff, you better make it
static (else they have to depend on really new versions of distros) and
also make it very lightweight, libc type stuff. Most of this closed
source stuff has to install on distros 5 years old, and continue to work
on distros 2 years in the future.

> Second, this way of distribution will help open-source projects as well.
> It would make it really easy for them to distribute bleeding-edge
> versions of there apps that integrate well into the packaging system
> without having to package for each and every package manager.

Talk to the distro maintainers. They really don't want random projects
replacing supported packages. Packages are not normally just the
upstream tarball with a spec file - normally the packager includes spec
files to make the package compile, or integrate well with the distro.
Then there's the world of pain that comes from security errata.

I really think you should talk to distro maintainers as well as closed
source vendors before coming up with any more API.

Richard.