On Sun, 2008-06-22 at 14:15 +0100, Richard Hughes wrote:
On Sat, 2008-06-21 at 11:51 +0200, Denis Washington
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
. Considering that third-party software installation is an undeniably
important weak spot of the Linux infrastructure, I found this was a
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.
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:
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:
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
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
implementation currently supports integration into RPM and dpkg; due
to its modular nature, support for more package managers could be added
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.
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org