On May 19, 2010, at 2:26 PM, Denis Washington wrote:

> 
>> Meanwhile, what you are describing (and guessing from your previous freedesktop-like
>> implementation), you might as well just use PackageKit, which already has backends
>> and more.
>>   
> 
> Interesting how often my proposal was directly compared to PackageKit (including PackageKit author Richard Hughes himself) just because of the choice of technologies.
> 

Fear not: I'm hardly confusing your previous "Bergdorf API" implementation
with PackageKit (which I think is a bit silly as tools go).

However, you _DID_ choose certain technologies from GNOME freedesktop for your
"Bergdorf API", and the largest objections (not from me) were that
you had used GNOME freedesktop API's prematurely/incorrectly. (All from memory,
I'll dig out details for my delusions if necessary; I'm certainly not disagreeing/arguing
what you are/were trying to do or did, I'm an innocent bystander here ;-).

> PackageKit is designed as an interface for installing distro-specific packages or getting specific packages from distro-specific package repositories. That's its use case. Registring software in the package manager's database that does *not* come in the form of a native distro package is completely outside of that use case. Adding that to PackageKit would not make much sense imho. Also, PackageKit is not used in many distros (only in RHEL probably) so it is by far not a candidate for inclusion into the LSB.
> 

No need to explain: PackageKit is silly/foolish as tools go. JMHO, YMMV, everyone's does.

> Also, I am aiming for a more low-tech implementation this time. As the fallback implementation must work without being installed on the system, things like registered D-BUS services and PolicyKit are a no-no anyway. A simple library depending only on libc (and glib, if I'm lazy, plus the package-manager-specific libraries used in the backends) will most probably do, assuming the installer will run as root (which is no worse than existing ISV installers).
> 

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.

>>> - In parallel, fill the holes in the LSB RPM spec (possibly uplifting to v4) and try to synchronize the metadata semantics with the ones of the package API (meaning, probably, that the package API will end up receiving RPM semantics at many places). This means we will have the package API for things like cross-platform installers on the one side and the RPM format as an alternative direct format on the other side, and we may be able to keep compatibility with the old RPM spec. (Crucial as the LSB 4.x series is committed to backwards compatibility.)
>>> 
>>>     
>> Please, its the "LSB format" spec, not the "LSB RPM spec".
>> 
>> The distinction is crucially important.
>> 
>> What LSB has chosen to make "standard" has nothing to do with RPM for
>> many years now.
>> 
>>   
> 
> As you please.
> 

(aside)
I've wasted months of my life on the confusion between LSB <-> RPM.

Enuf: LSB != RPM. Period. They are different implementations and different "branding".
If you want a "LSB package" installer/format/brand/whatever, well its silly to
talk on an RPM list for a LSB "product" and/or "standard".

>>> There are probably a lot of issues with this path, but it might be a good start to experiment with. What do you think?
>>> 
>>>     
>> For register/unregister (and "transactionally protected" ACID behavior), I'm
>> currently embedding sqlite3 in RPM, and using sqlite3 "virtual tables" (VT) as
>> an abstraction for register/unregister (largely because sqlite3 VT have two
>> phase commit methods), and using SQL as a data focussed implementation language.
>> 
>> Note "data focussed" and de facto bog-standard as the basis for choosing SQL.
>> I don't particularly like SQL or sqlite3 implementation languages.
>>   
> 
> Unfortunately I don't understand what exactly you are trying to do. Could you elaborate a bit on this?
> 

I'm looking for "package" register/unregister methods (a la the "Berlin API") implemented directly in SQL.

All the rest of what I said are implementation details.

73 de Jeff