On May 7, 2009, at 1:03 PM, Mark Hatle wrote:

> 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.
>

That was the sense of you message, yes.

BTW, there is /usr/lib/rpm/helpers/makeshlibs already,
only 53 more debhelper scripts, with a media size of ~2.7 lines
of shell, to go.

And when /usr/lib/rpm/bin is populated with grep/wget/bash/tar/cpio/...
well, I think you know how much simpler RPM's AutoFu defaults will
become.

> 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).)
>

Cool! That's exactly the usage case that was intended, you are one of  
the
first to report using the implementation 9+ years later.

>>> 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'.
>

daughter tallied as an e), a wise choice.

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

Hmm, but you end up in d), as "either a) or b)" is not one of the  
choices ;-)

Seriously, I have conventions for multiple paths that I need to
achieve consesnus about, including debhelper-like and private
executable paths, some I'm more or less just clowning around
while y'all figger out that yes, indeedy, there are multiple
sub-directories that are about to appear in /usr/lib/rpm.

Like all path choices ... *yawn*

73 de Jeff

> --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
>
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org