unsubscibe

[Corey Campbell]

unsubscribe
--- voltaire at idirect.com wrote:

> unsubscibe
> 
> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com
> [mailto:fedora-devel-list-bounces at redhat.com] On
> Behalf Of Denis Washington
> Sent: Tuesday, June 24, 2008 10:05 AM
> To: rpm-lsb at rpm5.org
> Cc: Development discussions related to Fedora;
> packaging at lists.linux-foundation.org;
> opensuse-project at opensuse.org;
> lf_desktop at lists.linux-foundation.org;
> ubuntu-devel-discuss at lists.ubuntu.com;
> rpm-maint at lists.rpm.org;
> debian-dpkg at 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 at redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-devel-list
>