LSB Package API

Wed Jun 25 18:35:42 UTC 2008

I recently installed SPSS (a closed-source statistical program), and the
downloaded .bin file for Linux contained an installation progam using
Installshield (probably the same as they are using on Windows).

I'm pretty sure the SPSS people don't want to invest in switching
installation system, or make any other big changes to it. They also probably
wants to use the same installation system they use on Windows. It would be
relatively easy for the Installshield guys to add support for the Berlin
API, and for SPSS to take advantage of that. That would make it possible for
the files it installed to show up in some way in the dpkg system, and I
could then manage it via synaptics. And that'd sure be nice!

I'm not an expert in the field, but from what I can understand, none of the
existing solutions out there provide this feature, and in a way that is so
easy to implement (and learn) for the ISVs (and installation program
makers).

To those who say ISVs anyway targets specific distributions: Yes, they would
still have to test it on all the major distributions, but they could use a
single installation implementation. And they would have to learn only one
system (which, if they are using Installshield-like software, is mostly the
same as on Windows). And I'm quite sure most ISVs sees these two things as a
big advantage.

Sure it would be much better if they had made a real .deb for me, but them
using something similar to this would sure be much better than what they
have today. And as SPSS and many other companies probably don't want to
spend so much time and money on the Linux installer, many of them won't in
the for-seeable future do something which is a too big change from what they
use (and know) today. Maybe sometimes in the future when Linux has gained a
much larger market-share than today, but until then, the Berling API would
certainly be good. If this Berlin API actually becomes widely adopted, and
the ISVs still won't make the effort to support it, that's bad. But if they
can't even support something as simple as this, then they will not support
any of the other systems (which, as far as I can judge, are more complicated
for them). So, as an end-user sometimes installing programs from ISVs, I'm
definitely in favor of the Berlin API, as I'm hoping it will ease things a
bit for us.

Regards
Pär Lidén

2008/6/24 Denis Washington <dwashington at gmx.net>:

> 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
>
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20080625/29a6117c/attachment.html>