On Sun, 2008-06-22 at 14:15 +0100, Richard Hughes wrote: 
> On Sat, 2008-06-21 at 11:51 +0200, Denis Washington wrote:
> > 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.
> 
> Sure, it's been tried before a few times before and fallen on it's face
> each time. There's a reason that PackageKit uses the distro supplied
> packages, rather than trying to spin it's own thing.

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.

> > 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
> 
> Sounds quite like PackageKit, which has been developed for the last year
> or so with buy-in from most of the big distros. PackageKit doesn't try
> to replace the entire stack, only make some sort of abstraction for GUI
> tools where such an abstraction makes sense.
> 

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.

> Being blunt, no distro is going to support a LSB package API. To me, a
> distro is basically:
> 
> community+trust+infrastructure
> 
> If you take away the trust (letting other people create and sign
> packages), the infrastructure (letting other people host packages and
> manage security errata) and the community (basically reduced to PR)
> you've got nothing left.
> 
> The cost of a distro rolling it's own packages is trivial considering
> the advantages of the vendor trust model, with a single infrastructure
> and support.

The distro model is nice (and arguably better than the LSB Package API)
if the packages you like to have are in the repos in sufficiently new
versions. But if you need to go past that (bleeding edge versions, not
widely spread apps), things get more difficult currently. Especially
propietary applications just cannot be distributed by the distros
directly.

> > The implementation currently supports integration into RPM and dpkg; due
> > to its modular nature, support for more package managers could be added
> > later on.
> 
> Looks like you've not considered localisation, multi-lib, multiple
> versions of packages, or any of the problems solved with solutions like
> NEVRAs. I would suggest to read the rpm(+yum), dpkg and conary sources
> before you even start to propose APIs.

Naturally some things are not considered yet. That's  why I called the
spec and implementation I released a "starting point", not the
completely finished thing ready for production. There are quite a few
points that will have to be thought through and added, but I don't think
it's impossible to do so on top of the current basic design.

> > 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! ;)
> 
> I think you are looking for a solution to a problem that doesn't exist.
> For the corner cases of where this does apply (proprietary software)
> this is not enough of a use case to justify all the work required.

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.

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. It will
also help those projects which are not widely used enough to be in
distro repos, as they can more easily release binary distributions
without having to depend on getting packaged by the distros. I really
believe this decentralism would be very nice to have, especially in
something as naturally decentralized as the open source community.

Regards, 
Denis