On Sun, Jun 22, 2008 at 01:34:31PM -0700, Dan Kegel wrote:
> On Sun, Jun 22, 2008 at 11:02 AM, Denis Washington <dwashington@gmx.net> wrote:
> > 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.
>
> Sure, and that's why I support the LSB.
> Has everybody else given up on it?

I've probably missed part of this discussion, but wanted to inject one
anecdote.

Stand-alone binary package installers are nothing particular novel or
new; I'd gained experience using one, Autopackage, with Inkscape several
years ago.

Inkscape was virtually unknown at the time, so Autopackage gave us a
significant benefit of providing users a way to quickly get Inkscape on
distros that didn't yet include Inkscape.

Before Autopackage we would maintain our own .deb and .rpm rules and
specs, and we hoped Autopackage would obsolete that in favor of having a
"Universal Installer". Yet that really never came to be.


First, Inkscape became recognized by distros, and they took over
handling our packaging work for us. Meanwhile, the Autopackage
developers (who had been subsidizing us by maintaining the .autopackage
file for us), turned maintenance over to us. So on the one hand we were
seeing our team workload *reduce* by relying on
packaging-system-specific stuff, and *increase* by using autopackage.

You might argue that it's different for proprietary software since
distros wouldn't adopt them. Yet look at Xara, Flash, Opera,
proprietary Java, and so on to see that they can and do (to the level
they're able anyway).


Second, while in theory Autopackage promised "100% easy install,
anywhere", it was not without problems. The issue always seemed to be
with low level dependencies that varied just subtly enough to break on
one distro or another. So you ended up doing per-distro testing anyway
(and couldn't count on help from the distro once you figured out the
bug).

I think this is an important point to not dismiss by saying, "The design
wasn't as good as ours is", or "it just needed more testing", or
whatever. The sad truth is that getting this to work 100% requires
invalidating Murphy's Law. It's a broad fronted fight against entropy.

I felt like we had tried to change our support from N distros to 1, yet
ended up with N+1.


Third, as Inkscape grew we had to account for more dependencies.
Typically, there'd already be .rpm and .deb packages for them, but we'd
be stuck having to do the autopackage packaging work ourselves.

Now, you might think such an issue is irrelevant for proprietary
software since they'd be packaged with all dependencies already
included. Yet consider dependencies beyond just dynamic libraries.
Consider if the app wants to interface with external programs or tools
(imagemagick, java, sqlite, ...) or to shared data repositories
(openclipart, fonts, etc.)

Eventually, you find yourself having to do a lot of work that distros
already take care of.


Anyway, to sum up, as much as I loved the idea of autopackage and helped
to advocate it, I really don't think the idea of a "universal installer"
is viable. In the end it's a lot less effort to just collaborate with
each of the distros and have packaging optimized for each. And I think
efforts put into creating yet more universal installer techs maybe
better invested in helping bring the existing packaging systems better
into consistency with one another, or establishing "best practices"
documents.

Bryce


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

> 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.

> 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.

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.

> 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.

I really think you should talk to distro maintainers as well as closed
source vendors before coming up with any more API.

Richard.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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

> 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.

> 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.

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.

> 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.

I really think you should talk to distro maintainers as well as closed
source vendors before coming up with any more API.

Richard.



--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, 2008-06-22 at 11:41 -0800, Jeff Spaleta wrote:
> On Sun, Jun 22, 2008 at 10:02 AM, Denis Washington <dwashington@gmx.net> wrote:
> > 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 do not want to make proprietary applications easy to install. My
> involvement in Fedora is predicated on the idea that everything I do
> as part of my involvement with this project makes it easier for people
> to stop using proprietary applications. I would strongly suggest that
> you don't stand up proprietary applications as your primary argument
> or use case for the technology. If you want this considered seriously
> by this community. Stand up a usage case which benefits open source
> software and wok through that usage case.

Bleeding-edge versions of open-source projects. It would likely benefit
project maintainers to provide installers for new versions of their
software so that users can easily install and use them, even if the
stable version of their distro does not provide the newer version.
Especially trying some beta or release candidate (which no stable distro
will ship) would be made a lot easier. This could in turn increase the
number of people testing a pre-release version of their favorite
open-source applications and, thus, expose more bugs that can be fixed
before the final release. And everybody's happy.

Another usage case is the distribution of very young and small
open-source applications. Those often suffer from not being in any major
distro's repositories yet. If they could provide an installer which
installs the application in all major distros and even integrates it
nicely into the packaging system, more people will be likely to give the
new application a try than when there are just packages for certain
distros or even nothing more than a source distribution. So I see strong
benefits here too.

Anyway, I don't think that we should not make lifes difficult for
propietary application vendors just because some don't like them. I
respect your dedication to a pure free software system, but I don't
think we should force this opinion of all users of Linux. Having an easy
way to install propietary applications does not mean that anybody has to
install such software. It should be easy to those who want (or need) to
do so - and that's a goal of the LSB Package API.

> > 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.
>
> If its that bleeding edge, should it tie in to the packaging system,
> potentially causing problems for the distribution dependency
> resolution?

There will not be any dependency problems. An LSB-compliant application
is required to bundle all libraries which are not guaranteed to be
provided by the LSB, so it won't interfere with the base system here.
Additionally, as much as possible is installed to /opt, so that no
conflicts with distro packages arise.

> Or should it be more like autopackage built as a secondary system?
> Aren't you just re-inventing a new implementation for the problem that
> autopackage has been attempting to solve for years now? In fact I
> think you should go back and look at autopackage and make a compare
> and contrast between the APIs. I know why I don't like autopackage.
> it would be useful to know if I'm going to dislike your API for the
> same reasons.

I must admit that I haven't looked much at autopackage yet. I will have
to evaluate it thoroughly in the next days to make a good comparison.
But it is important to note that the LSB Package API is _not_ a
secondary package manager; it always uses the distro's packaging system.

Regards,
Denis

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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@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@lists.ubuntu.com

Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

On Wed, Jun 25, 2008 at 8:35 PM, Pär Lidén <par.liden@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)


Problem:

Q- it is repetable the installation ? It is simple to install on many system in batch mode, without human intervention?
R: No
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 ?
R- No

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 management system.


Sorry for the long post.
*
Regards




*
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@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@lists.ubuntu.com

Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss




_______________________________________________

Rpm-maint mailing list

Rpm-maint@lists.rpm.org

https://lists.rpm.org/mailman/listinfo/rpm-maint

On Mon, 2008-06-23 at 15:14 +0100, Scott James Remnant wrote:
> My general feeling, having spoken to lots of ISVs, is that they don't
> actually _want_ this.
>
> In order to support their customers, they're well aware that they have
> to target particular distributions and versions - and they're quite
> happy working and certifying particular vendors individually.

I'm not in the position of having the chance to speak with ISVs myself
unfortunately. I only relied on what seemed to have been communicated on
the LSB face-to-face meeting. It might be good if we had more
application vendors (and also open-source project maintainers) speaking
up on this issue in the general or the particular proposal.

Regards,
Denis


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org