On Oct 31, 2010, at 10:45 AM, Eric MSP Veith wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 30 October 2010, Eric MSP Veith <eve...@wwweb-library.net>
> wrote:
>> What would really be cool is if the bindings code could get the
>> success/failure of an expansion/addition/deletion. I.e., get rid of the
>> (void) case before an rpmExpand call and map it into a nice Ruby
>> exception. Perhaps via an extern int macroRC definition or something
>> like that?
>
> Btw:
>
> rpmExpand & Co return an int and I guess this is meant to be the RC/error
> code of the function. This isn't used because there's currently no way to
> return the actual error code from the underlying doDefine() & Co.
>
Yup. Lots of places where (even if proper errors are returned) nothing
uses or cares to check the error code.
> What about either adding an rpmRC* error to the method signatures of
> doDefine & Co, or changing their signatures to return the rpmRC, and making
> the parse address one parameter?
>
And here the issue is API/ABI: If the library API/ABI changes
in any way at all, then all that happens is lusers start chanting
RPM has no stable API/ABI!
Well, yeah: RPM has _NEVER_ had a stable API/ABI, and (because
the RPM version is imprinted into library names), has _NEVER_
promised a stable API/ABI, nor is there any real need.
So there's a fundamental deadlock that stops all proper engineering.
Meanwhile, rpmExpand et al have almost nothing important to do with
"package management". The really hard issues with error returns are
on the install paths, with depsolvers in bindings like yum/smart/urpmi,
thare expecting rpmlib to Just Work and are _ALREADY_ ignoring
error codes most everywhere.
I expect Ruby to be about the same: DWIM.
Meanwhile the important issue is _NOT_ what rpmlib returns, but rather
ensuring that the design of the ruby bindings is architecturally correct.
In C, its a very common paradigm to do:
if (someRoutine(..))
fprintf(stderr, "Danger Will Robinson! Error! Error! Error!\n);
That C paradigm just doesn't fit into most bindings, which (if intelligently
designed)
usually return "self" or "this" so that methods can be recursively nested like
fooClose( fooRead( fooOpen("/some/file", ...) ...) ...)
Focus on the ruby binding design, exceptions (or mappings to NIL or NULL or
EMPTY) can
be arranged whenever you are sure that you have a tasteful/intuitive/aesthetic
ruby binding paradigm.
But it will take a few more objects (and more important objects than macro
contexts
and Bloom filters) to get a paradigm in place imho.
> Or is it "wait for C++ and a well-defined RPM5 exception/error path"?
>
That's one approach. There are others. But returning rpmRC for macros in ruby is
gonna have a ripple effect everywhere that is quite costly to stabilize.
Note that I'm not averse to change, just, well, there's _LOTS_ of coupled side
effect issues.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
