Ok.. I understand now.. then my suggestion is that these should be macros so 
that individual distributions can set specific initialization options.  A 
reasonable default macro should be provided as well.

(In many ways I equate this to the various pre/post-prep, build, and install 
macros that already exist.)

--Mark

Jeff Johnson wrote:
> 
> On May 7, 2009, at 9:57 AM, Mark Hatle wrote:
> 
>> Then I misunderstood the original question.  I was reading it as to 
>> what path(s) are used to initialize the interpreters.. i.e. load 
>> includes, modules, etc. That is what I was referring to.
>>
> 
> ATM, the embedded interpreters have initializiation strings
> that are eval'd when an embedded interpreter is instantiated.
> 
> I'm looking for where to put those strings so that the
> strings can be changed without recompiling rpm.
> 
>> As for the interpreters themselves, I'm not really sure.  I can see a 
>> case for both system level paths and paths inside of the /usr/lib*/rpm 
>> framework.
>>
> 
> There are many issues. I'm asking the very narrow issue of where to put,
> say, this text that is eval'd every time an embedded perl interpreter
> is fired up:
> 
> /*@unchecked@*/
> static const char * rpmperlInitStringIO = "\
> use strict;\n\
> use IO::String;\n\
> our $io = IO::String->new;\n\
> select $io;\n\
> use RPM;\n\
> ";
> #endif
> 
> The other issues of integrating with existing path conventions
> of interpreters are equally important.
> 
> Guess what I ask next ;-)
> 
> 73 de Jeff
> 
>> --Mark
>>
>> Jeff Johnson wrote:
>>> On May 7, 2009, at 9:15 AM, Mark Hatle wrote:
>>>> I like the idea of changing the locations to be loaded into macros.  
>>>> This helps my relocatable RPM mechanism.. ;)
>>>>
>>> Using a macro for the path doesn't tell me what I asked:
>>>    Where should per-interpreter initialization and
>>>    private JS extensions be installed?
>>>> 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.
>>>>
>>> If the stuff isn't installed (because no path has been chosen),
>>> then its impossible to consider using the "stuff" outside
>>> of a rpm build tree.
>>>> 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..)
>>>>
>>> I need answers for what path, not how to "Have it your own way!" using
>>> macros.
>>> 73 de Jeff
>>> ______________________________________________________________________
>>> RPM Package Manager                                    http://rpm5.org
>>> Developer Communication List                        rpm-devel@rpm5.org
>>
>> ______________________________________________________________________
>> RPM Package Manager                                    http://rpm5.org
>> Developer Communication List                        rpm-devel@rpm5.org
> 
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org