On Aug 22, 2011, at 12:07 PM, Anders F Björklund wrote:
>>
>> Yup: the only reason for including python/* and perl/* and js/*
>> and ruby/* and tcl/* is to provide one-stop-shopping.
>
> The js/* is still the preferred/"mandatory" scripting, yes ?
Its "preferred" by me still yes. And with js-1.8.5 its
feasible to make it MANDATORY (though MANDATORY sounds like
I'm a dictator, when its really the reverse:
rpm cannot use any functionality that isn't
GUARANTEED to be present
> (with it being included in MongoDB and everything, that is)
>
>> But there's so little interest in FL/OSS development that its time to
>> let the code float away … with "embeddings" rpm can target development
>> issues for all development language problems, not just whatever feebleness
>> to do
>> rpm -qa
>> in Newer! Better! Bestest! ways has been devised in that particular scriptie
>> dialect.
>
> A shared rpmlib binding might have worked - for a stable API…
Its not just the "stable API": each and every binding has its
own special methods abstractions on same old same old.
> Then each script could "canonicalize" on top of the C functions.
>
Well there is SWIG that can be attempted off RPM converts to C++.
SWIG benefits from sub-classing is the reason: and all rpm objects
are essentially derived from a base class now that muteness are reliably
attached everywhere. Just its not C++! C++! C++! yet.
> Noting that the ruby-rpm links directly to popt and db. Sheesh.
>
In addition to -lrpmdb? Or instead of -lrpmdb? The second actually
makes some sense, and using /var/lib/rpm/DB_CONFIG to set tunables
makes it (almost, headerLoad()/headerGet() are still needed) almost
feasible to read an rpmdb without using RPM at all.
That is/was the intent choosing Berkeley DB ages ago ...
73 de Jeff______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
