On May 19, 2010, at 10:12 PM, Jeff Johnson wrote:
Are you writing an "ISV installer"? A "standard" specification? Resurrecting the
"Bergdorf API"?
All or some or any of the above?
I cannot yet tell ... meanwhile the "Bergdorf API" got farther along than
any other implementation, so please -- no need to apologize for anything.
Sorry for not being clear enough, let me explain again. There are only
two things I am proposing for the LSB:
- A sufficiently precise definition of a package and it's accompanying
metadata.
- A VERY simple API for notifying the system package manager of the
installation / removal of such a package.
Distributions would be encouraged to implement this API in their system
package manager for third-party installers to use. Likewise, ISV's and
cross-platform installer authors would be encouraged to use that API. So
if an installer uses it, and the system's package manager supports it,
the installed package is registered correctly in the native package
database, and all is fine and dandy.
So far, so good. Now here's the problem: no distro / package manager
currently supports the API, naturally, because it is not something that
already existed before. And because this is the LSB, it _must_ already
exist in the current enterprise distros before it gets into the
standard. So even if the API would be implemented NOW, we would have to
wait about 2 to 4 years before even the major enterprise distros have
adopted it, and another year or so before it is officially part of the
standard.
What would that mean for ISVs? Right: the API would be completely
irrelevant. Naturally, they COULD modify their installers to use the API
if available and the old way otherwise, but why bother if really no
single LSB-certified enterprise distro has support for it? Even if
adding support for the API was cheap as dirt, there just wouldn't be any
point.
Which might let the distro makers think: if no ISV will use the API
anyway, is there any point in implementing it at all?
The classic chicken-and-egg problem.
Having realized this, it should be clear that there must be a transition
path between "nobody implements / uses the API" and "(almost) everybody
implements / uses the API". And this is where the code *I* am planning
to write comes into play: an implementation of the API that can be used
by installers NOW by statically linking to it. That implementation will:
- query the system package manager for an implementation of the API, and
use that if available.
- will use an built-in fallback mechanism if the system package manager
does NOT implement the API, provided the package manager is known to the
fallback implementation. In the case of rpm, this would probably be
similar to the rpmlib hackery I showed you with the Burgdorf API.
- do nothing if there is neither a system nor a fallback implementation,
that is, package (un)registration will be a no-op.
Using this fallback implementation, an ISV would have the instant
benefit of increased integration with the native packaging system by
using the API now. At worst, in the case of more exotic package systems
without existing fallback (the ISV has probably not supported that
before, anyway), the (un)installation process would be as badly
integrated as before, so using the API would be win-only. Because of
this, chances are that the API gets more widespread use, which in turn
might get package managers to implement the spec, which in turn makes
integration better because the fallback mechanisms don't have to be
used, which in turn makes users happy, which in turn makes ISVs and
distros happy... you get the idea.
How does that sound?
Regards,
Denis
______________________________________________________________________
RPM Package Manager http://rpm5.org
LSB Communication List rpm-lsb@rpm5.org
