FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 06-24-2008, 02:07 PM
 
Default unsubscibe

unsubscibe

-----Original Message-----
From: fedora-devel-list-bounces@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@rpm5.org
Cc: Development discussions related to Fedora;
packaging@lists.linux-foundation.org; opensuse-project@opensuse.org;
lf_desktop@lists.linux-foundation.org;
ubuntu-devel-discuss@lists.ubuntu.com; rpm-maint@lists.rpm.org;
debian-dpkg@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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 06-24-2008, 03:05 PM
Corey Campbell
 
Default unsubscibe

unsubscribe
--- voltaire@idirect.com wrote:

> unsubscibe
>
> -----Original Message-----
> From: fedora-devel-list-bounces@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@rpm5.org
> Cc: Development discussions related to Fedora;
> packaging@lists.linux-foundation.org;
> opensuse-project@opensuse.org;
> lf_desktop@lists.linux-foundation.org;
> ubuntu-devel-discuss@lists.ubuntu.com;
> rpm-maint@lists.rpm.org;
> debian-dpkg@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@redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-devel-list
>





--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-03-2010, 05:58 PM
Jeff Gamsby
 
Default unsubscibe

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 04:06 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org