[Commenting on this thread is a disaster; different people strip off
different mailing lists, and parts of the conversation are happening
everywhere. Can we all agree, at least, to keep the packaging list in
followups?]
Richard Hughes wrote:
Being blunt, no distro is going to support a LSB package API.
In 2006, representatives from Red Hat, SuSE/Novell, Debian, and Ubuntu
committed in principle to doing just such an API once it was done.
Of course, that's not a guarantee, but it holds a little more weight, I
think, than the above quote.
At that 2006 meeting (December, in Berlin, thus the "Berlin API" name),
these representatives from the distros were told by numerous ISVs why
distro package systems were not acceptable. The Berlin API was a
compromise; the idea was that third-party software installers and
package managers would be able to communicate and cooperate.
Part of the issue may be that most of the implementations so far have
assumed that communication from a third-party installer would result in
a pseudo-package being registered in the native package database, which
leads people to believe that this is a "new package format" of some
kind. The original idea, though, was for a communication protocol only.
The native package manager may decide to store the results by creating
a pseudo-package, but does not *have* to.
I think we're willing to accept that the particular implementations of
the Berlin API idea are wrong-headed, and perhaps re-do them. But the
general idea--accepting that things such as InstallShield and
InstallAnywhere are going to exist, and finding a way for them to
cooperate with the underlying system instead of fighting with it--isn't
something I see anyone else trying to address.
______________________________________________________________________
RPM Package Manager http://rpm5.org
LSB Communication List rpm-lsb@rpm5.org
