On Aug 22, 2011, at 6:57 AM, Anders F Björklund wrote:
> Tobias Gerschner wrote:
>
>> What's the state of ruby bindings in rpm5? The last discussion I remember
>> was centered around the absence of an usable API for ruby >= 1.9.
>
> There are no ruby bindings in rpm5, only ruby embedding…
The difference between binding and embedding is largely moot.
There's a top-level executable that loads modules: the difference
is largely whether that executable is called /usr/bin/ruby or
/usr/bin/rpm or /usr/lib/rpm/bin/rpmruby.
> (the old bindings were GPL, rather than LGPL like python)
>
Yes: the *existing* (and largely orphaned/defunct afaik: the project
was seeking a new maintainer a couple years back and GPL instead
of LGPL prevented adoption by @rpm5.org) ruby bindings for rpm
are GPL. And there's no interest I know of (in fact the usual negative
interest in anything produced @rpm5.org because of Fork You! politics)
in the rather minor patch to use the existing ruby bindings with
@rpm5.org code.
> And Ruby upstream support for embedding is still very poor.
>
This isn't true. There are two issues here:
1) ruby 1.8.x != ruby 1.9.x incompatibilities
2) ruby-1.9.x embedding needs a separate persistent stack.
The support for embedding in ruby-1.8.x is fine: as good as any
other embedding (which usually isn't very good for any interpreted
language, perl/tcl/lua being the outstanding exceptions.)
The need in ruby-1.9.x is largely an architectural constraint.
What SHOULD (and did when I prototyped) work fine is to put the
ruby embedding on a separate thread with its own stack, and
use intra-thread communication to interpret ruby code at run-time.
But the architectures needed for embedding in ruby-1.8.x and ruby-1.9.x
are rather different, and "Have it your own way!" and the expectation
that ruby == ruby likely dooms the usefulness of pursuing ruby embedding
@rpm5.org.
But I definitely know what to do with both embeddings and bindings, and
with ruby 1.8.x and 1.9.x, and with rpm.org != rpm5.org API.
Lack of any significant development interest in rpm+ruby with a clearly
defined ROADMAP deliverable is all that stops doing whatever ...
>> I'm very interested in seeing ruby-rpm bindings for rpm5 work for a project
>> I'm working on : http://code.google.com/p/ubuild-linux/ .
>
> It would probably be easier to do this using python, those
> bindings are bad enough without suffering the non-standard ?
>
Heh: I pointed out a fairly significant flaw with
static FD_t fd;
in the python bindings yesterday. At some point its easier
to start from scratch in ruby than it its to pretend that
the rpm-python bindings are "useful".
> The only project I know about using ruby-rpm is enhancerepo.
>
Yes: Duncan McVicar (and OpenSuSE) are most of the active interest
in rpm-ruby afaik. There *is* a great deal of interest in rpm-ruby
in Japan, but that is usually off my radar (but there is other interest
in rpm-ruby).
>> I'm currently using rpm-5.2.xx and for all I know rpm-ruby bindings are
>> currently not functional.
>
> The patches for rpm5 were unfortunately rejected upstream.
> So only rpm.org is supported, similar to apt-rpm and yum.
>
> http://rubyforge.org/projects/ruby-rpm/
>
And I can fork ruby-rpm just like I've forked yum/createrepo @rpm5.org in
order to deliver a patch to use the existing ruby-rpm bindings with @rpm5.org
code whenever there is need or interest.
GPL != LGPL stops one and only one thing:
RPM from @rpm5.org is LGPL: no GPL code can be included
in rpm-X.Y.Z.tar.gz when released.
hth
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
