unsubscribe --- voltaire@xxxxxxxxxxx wrote: > unsubscibe > > -----Original Message----- > From: fedora-devel-list-bounces@xxxxxxxxxx > [mailto:fedora-devel-list-bounces@xxxxxxxxxx] On > Behalf Of Denis Washington > Sent: Tuesday, June 24, 2008 10:05 AM > To: rpm-lsb@xxxxxxxx > Cc: Development discussions related to Fedora; > packaging@xxxxxxxxxxxxxxxxxxxxxxxxxx; > opensuse-project@xxxxxxxxxxxx; > lf_desktop@xxxxxxxxxxxxxxxxxxxxxxxxxx; > ubuntu-devel-discuss@xxxxxxxxxxxxxxxx; > rpm-maint@xxxxxxxxxxxxx; > debian-dpkg@xxxxxxxxxxxxxxxx > 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- > fedora-devel-list mailing list > fedora-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
