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 <div class="gmail_quote">2008/6/24 Denis Washington <<a href="mailto:dwashington@gmx.net">dwashington@gmx.net</a>>: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">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 </div>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. <div class="Ih2E3d"> > > 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, <a href="http://www.linuxfoundation.org/en/LSB_Package_API" target="_blank">http://www.linuxfoundation.org/en/LSB_Package_API</a> 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. </div>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). <div class="Ih2E3d"> > > 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. </div>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. <div class="Ih2E3d"> > 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. </div>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.) <div class="Ih2E3d"> > > 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. </div>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). <div class="Ih2E3d"> > I really think you should talk to distro maintainers as well as closed > source vendors before coming up with any more API. </div>A number of ISVs have already been talked to; see the comments from Jeff Licquia. Regards, Denis <div><div></div><div class="Wj3C7c"> -- Ubuntu-devel-discuss mailing list <a href="mailto:Ubuntu-devel-discuss@lists.ubuntu.com">Ubuntu-devel-discuss@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss</a> </div></div></blockquote></div>