Am 20.05.2010 14:58, schrieb Jeff Johnson:
On May 20, 2010, at 4:03 AM, Denis Washington wrote:
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.
THis ounds like Yet Another Form of Markup Spewage. The definition of the
metadata
contents is nowhere near as important as the definition of the semantic
interpretation
of the content, or figuring how the spewage can be parsed into existing package
managers
when written in perl/python/ruby/java/ocaml/haskell/... etc.
Again, Mancoosi and Nix are closest to getting the semantic interpretation
precisely
defined. OTOH, neither OCAML or C++/perl are very useful for say, a
java/ruby/python
package manager implementation. Both CUDF and Nix were a rather painful amount
of effort to embed @rpm5.org in C (and neither of the implementations is very
pleasing as code goes, or useful to RPM functionality, so far).
I am well aware that the exact interpretation of the provided metadata
is central to the specification. Please, remember that I am currently
just presenting my general ideas, not a detailed definition of
everything that is needed.
- A VERY simple API for notifying the system package manager of the
installation / removal of such a package.
But what is the criteria for SIMPLE? Few methods with minimal arguments? Fewest
prerequisites (like perl/OCAML)? Smallest resource usage? Most widely
portable/available? Most distros/lusers who claim SIMPLE?
Its reliability that is usually more important criteria after design/development
(where SIMPLE is desirable because easiest to implement).
...
Simple in that
1. it only consists of a very small set of C functions (essentially
register+unregister, plus a few to assemble the package metadata) which
don't require any other library to be used
2. its "fallback implementation" will be written in standard C + libc
for maximum portability between Linux distributions (plus maybe package
manager specific libraries for the fallback mechanisms, but those are
only loaded if needed)
3. it is, because of the two properties above, _very_ simple to use from
different programming languages (almost any programming language used in
the real world can reasonably well interface with C).
Primarily I meant the first of these points: the interface should be
very narrow and not take a lot of effort to implement for a given
packaging system. (Provided the specified package semantics can be
easily mapped to the semantics of the native packaging system.)
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.
These are the flaws with an approach through an API.
Until the API exists and is widely deployed, noone will use the API
no matter what functionality the API provides.
...
That's the point of the fallback implementation: it allows ISVs to use
the API *before* it is deployed by the distros, providing them a
reasonable amount of integration when the implementation has a fallback,
and no penalty (opposed to the current situation) when not.
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?
Well, I said up front
An API (and a method based approach) isn't what is needed imho.
What is needed is a focus on data and emantics and access patterns.
I said as much to LSB when the "Berlin API" was first proposed.
In the risk of repeating myself: I know. I very well know. But this
doesn't change the fact that before anything else, there must be a way
for ISV-provided installers to communicate with the package manager.
Without that, all definitions of semantics have no practical relevance,
so that is why I am mentioning the API as a way to provide that. But as
we both know, the API is nothing more than that, the communication
channel; what the package metadata sent through this channel actually
*means* is what must be in the center of a future LSB packaging standard.
I hope I'll be able to draft a starting point for such a specification
soon so that I have more to show than vague ideas.
But if you can devise some reasonable spewage for encapsulating "package"
data, I'll try to embed your API @rpm5.org.
Great to hear.
Regards,
Denis Washington
______________________________________________________________________
RPM Package Manager http://rpm5.org
LSB Communication List rpm-lsb@rpm5.org
