On Jun 23, 2008, at 3:43 PM, Jeff Licquia wrote:
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.
Speaking as the developer of an installer that has to fight with
this all the time, all I'm really looking for is a simple command-line
utility to interface to the native package manager beneath me. A
simple abstraction layer in the style of the xdg-utils of the Portland
project. Something that didn't require root would be nice, but I'm
not sure how you'd handle this on a multi-user system.
As it is now, I have to manipulate the underlying packaging
system by-hand and through fake packages built at runtime and the
like. It's crap, but it's the only outlet available until something
better comes along.
I guess I don't understand what is so difficult about the
decision except that everyone has a better way than the other guy.
Make something simple that gets the job done. Believe me, plenty of
people will come along later and glom more crap onto it. It's open
source, after all.
Damon
______________________________________________________________________
RPM Package Manager http://rpm5.org
LSB Communication List rpm-lsb@rpm5.org
