Re: LSB Package API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

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

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

From somebody that's spent the best part of a year researching the
packaging formats and distribution of metadata, I don't see such a LSB
package API as a viable project.

Richard Hughes (PackageKit maintainer)



-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux