I like the idea of changing the locations to be loaded into macros.  This helps 
my relocatable RPM mechanism.. ;)

My only concern is how do we deal with working with roots or not?  In my case, I 
doubt I ever want to load interpreters from inside of a chroot, however I think 
I can fairly easily see a need for doing that within an installer framework.

Perhaps what is needed is a macro, convention, etc that indicates either to 
perform the chroot before the load.. or contains the path of the chroot for use 
within a macro  %{nil} if not set?  (Just thinking out loud of how I can use 
this for the cross-architecture installs..)

--Mark

Jeff Johnson wrote:
> So far I've (quite successfully ;-) avoided the issue
> of where/how/what/when per-interpreter initialization
> should come from.
> 
> Currently, the initialization is compiled in with the
> interpreter wrappers, which was quick and easy devel.
> 
> E.g., here's what %{python:...} loads when instantiated:
> 
> #if defined(WITH_PYTHONEMBED)
> static const char * rpmpythonInitStringIO = "\
> import sys\n\
> from cStringIO import StringIO\n\
> sys.stdout = StringIO()\n\
> import rpm\n\
> ";
> #endif
> 
> That goop needs to be slurped from an
> external configure file somehow.
> 
> Which means that RPM needs to commit to
> some convention for per-interpreter initialization.
> 
> What has been wired up with Lua was perfectly OK when
> just LUA was embedded. But those conventions, and
> --rpmlua, just aren't gonna scale to 5 interpreters.
> 
> What I'd like to see is a per-interpreter config macro
> carrying the usual colon separated paths that are slurped
> and loaded when an embedded interpreter is instantiated.
> 
> What I'd like to fix, is the hardwired compiled in paths
> for LUA, and remove --rpmlua as a compiled in option.
> A popt alias should suffice for all the emebedded interpreters,
> the only "feature" reversion is attempting to run
> the rpm executable without _ANY_ configuration. These
> days, while you can still override everything in
> RPM from the CLI, its highly unlikely you will achieve
> much joy, as way too much rpm configuration is already
> being loaded from all over the place. JMHO, YMMV.
> 
> I'll wire up some KISS convention like
>     /usr/lib/rpm/embed/{ruby,...}.init
> in a flash if there's consensus.
> 
> (new topic)
> I haven't a clue where to install js/libjsm.so, JavaScript
> has no clear conventional guidance for paths to search for
> extension modules. Shall I just dump libjsm.so into
> /usr/lib/rpm, or should I attempt /usr/lib/rpm/js/*
> instead?
> 
> 73 de Jeff
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org