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).
> - 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).
...
>
> 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.
...
> 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.
But if you can devise some reasonable spewage for encapsulating "package"
data, I'll try to embed your API @rpm5.org.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
LSB Communication List rpm-lsb@rpm5.org
