Jeff Johnson wrote:
> 
> On May 7, 2009, at 12:42 PM, Mark Hatle wrote:
> 
>> Jeff Johnson wrote:
>>> On May 7, 2009, at 10:55 AM, Mark Hatle wrote:
>>>> 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.
>>>>
>>> Look, you will get a macro, likely with colon separation for multiple
>>> paths, and globbing, and URI's, and security checks with digital
>>> signatures/digests as well as simple owner/permission checks ...
>>
>> Macros I was referring to are the __build_pre, __build_post and 
>> similar.  This style would allow basic initialization sequences such 
>> as the example you provided:
>>
>> use strict;
>> use IO::String;
>> our $io = IO::String->new;
>> select $io;
>> use RPM;
>>
> 
> AH, I refer to this as "templating", and rpm is doing lots and
> lots of templating these days, usually with macros or queryformats.
> 
> But yes -- if embedded interpreters are a keeper, still unclear --
> RPM will proceed through templating to assemble per-interpreter
> scripts much like is being done with shell on the build side.
> 
> But increasingly, eliminating user scripting, or at least enriching
> the set of scripts used by packaging ala debhelper, is more
> important (imho) than providing a flexible means to assemble
> complex scripts for extending package installs.
> 
> YMMV, everyone's does. But ISTRC reading a post from you suggesting
> that its not worth the effort of customizing package scripts on
> the list that has chosen to censor me to prevent my participation
> in RPM discusssions.

Not sure exactly which message you are referring to.. But my experience is that 
if you are basing your distribution off of another distribution, the more 
customization you do to the spec files, the more long term maintenance you have.

However, modifying the master rpm-macros can allow you to globally change 
default behaviors with minimal modifications to the spec files.  (This is the 
technique we are using when integrating Moblin packages into the Wind River 
build system.  We use the templating macros above to pre-define CC=, LD=, etc to 
the cross compilers.  Then adjust the %configure macro to include a reference to 
our config site file(s).)

>> I'm not sure anyone is going to be able to provide a definitive answer 
>> as to what text everyone wants to use.. so pick a default, pick a way 
>> for distros to customize and make the assumption nobody will.. ;)
>>
> 
> OK, let's try multiple choice ...
> 
> Where should embedded interpreters find their default initialization in 
> RPM?
> Should the, say, ruby initialization be stored in:
>    a) /usr/lib/rpm/embedded/ruby.init
>    b) /usr/lib/rpm/ruby/init
>    c) all of the above
>    d) none of the above
>    e) a Gucci purse

Umm, my daughter choses 'e'.

However either A or B would be fine with me.  :)

--Mark

> I will tally the votes and set about implementing a reasonable default 
> path ...
> 
> 73 de Jeff
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org