[Rpm-maint] Re: LSB Package API
pinto.elia at gmail.com
Fri Jun 27 13:15:34 UTC 2008
On Wed, Jun 25, 2008 at 8:35 PM, Pär Lidén <par.liden at gmail.com> wrote:
> 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 have had a similar experience with websphere on linux but i am sure for
experience that the problem is common at other . The "graphical and
interactive" installation program was Installshield. Result:
1- The installer had installed 6 rpm without no file - empty
2- The installer had installed an true - almost - rpm but it doesn't exist
apparently on in installation CD
3 - The installer had installed the websphere sw as is, without rpm.
4- For update the software i have - always interactive - apply some patch:
sometime worked fine, sometime no
5- The postinstaller of websphere changed my httpd.conf . The default
install is for websphere to run as "root" : nice.
6 - i have to patch manually some file of one of or four (iirc) jvm included
and have to create an init script ecc.
7- The installer want X windows and so : ok, exists also a silent install
The time necessary generally was 2 or 3 days ( often also more)
Q- it is repetable the installation ? It is simple to install on many system
in batch mode, without human intervention?
Q- Can i update my system thereafter with safety?
R: No as I don't know the dependency
Q- Can I update webshere on a live system without loss of services ?
So, guess: I had done an RPM (two, one was an rpmrebuild), the patch are
%patch, the deps are included ecc. and so i can live happy.
What is more i can install it, thanks at rpm, in a multiarch (32/64) system
and i can upgrade it online . Ok, it is a huge rpm (28000 files or so) but
who cares ? (sure for deb it is possible to do the some thing )
So, at the end, the question is :
sure that this installer method is a good reference model ? I prefer a good
package management system (as rpm or deb) and not an installer as this. As
everyone know there are basic difference between an installer and an package
Sorry for the long post.
> 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
> 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.
> 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
>> > > 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
>> > > 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
>> > > (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
>> > > 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
>> > > 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
>> Ubuntu-devel-discuss mailing list
>> Ubuntu-devel-discuss at lists.ubuntu.com
>> Modify settings or unsubscribe at:
> Rpm-maint mailing list
> Rpm-maint at lists.rpm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ubuntu-devel-discuss