unsubscibe
-----Original Message-----
From: fedora-devel-list-bounces(a)redhat.com
[mailto:fedora-devel-list-bounces@redhat.com] On
Behalf Of Denis Washington
Sent: Tuesday, June 24, 2008 10:05 AM
To: rpm-lsb(a)rpm5.org
Cc: Development discussions related to Fedora;
packaging(a)lists.linux-foundation.org;
opensuse-project(a)opensuse.org;
lf_desktop(a)lists.linux-foundation.org;
ubuntu-devel-discuss(a)lists.ubuntu.com;
rpm-maint(a)lists.rpm.org;
debian-dpkg(a)lists.debian.org
Subject: Re: LSB Package API
On Tue, 2008-06-24 at 12:03 +0100, Richard Hughes
wrote:
> 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
I don't know where you a heading. The D-Bus service,
pluggable backends,
the XML parser, and system activation are all things
that installers
don't have to deal with. They just use the few
functions from
liblsb_package.
> > 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.
Just because it does use the same technologies, that
doesn't mean the
APIs' scope is the same. You should know enough
about your project to
realize that the LSB Package API is focused on
entirely different needs
(providing an interface for third-party app
installers) than PackageKit
(provide an API for the packaging system, based on
distro repositories).
> > 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.
Again, ISVs don't have to deal with D-BUS etc. Those
are _implementation
details_. They can just use a simple C API which
could also be easily
wrapped into simple command-line tools.
> 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.
The LSB Package API would only be in newer versions
of the LSB, so
support of legacy distros is not that high on the
list. (On any older
distro, no one could rely on the API even being
there.)
> > 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.
No packages are going to be replaced. LSB
applications are required to
install to /opt, so nothing is overridden. Even the
package naming won't
clash (it's "lsb-<provider>-<package name>" in the
implemented RPM and
DPKG backends).
> I really think you should talk to distro
maintainers as well as closed
> source vendors before coming up with any more API.
A number of ISVs have already been talked to; see
the comments from Jeff
Licquia.
Regards,
Denis
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com