On Dec 25, 2007, at 12:26 PM, Ralf S. Engelschall wrote:

> On Tue, Dec 25, 2007, Jeff Johnson wrote:
>
>> Just to check that I'm reading the code correctly:
>>
>> You're serializing all pkg NVR on the build machine into
>> an arbitrary Environment: tag using {} as a separator
>>
>>   Environment: N-V-R{}N-V-R{}....{}
>
> No, the value of Environment is set to a real (recursive) Lua table
> construct: { ["N-V-R"] = {<env>}, ["N-V-R"] = {<env>}, ...} where
> the <env> parts are the same type of table constructs reads from
> "Environment" tags of all the installed packages.
>

Ok, so you have tuples attached to a N-V-R retrieval key serialized
in lua script in an arbitrary Environment: tag.

There's got to be a better way ;-)

Again, I'm all for "works" and am ecstatic to see someone actually
use rpmlua, but there's gotta be a better, and more maintainable,
representation with a modest amount of thought and implementation.

>>> [...]
>>> %description\
>>> %{?__hook_description_1}\
>>> %{?__hook_description_2}\
>>> %{?__hook_description_3}\
>>> %%description
>>
>> This assumes that %description is the 1st section marker that causes
>> the parser to leave preamble parsing.
>
> Correct. Not a generic solution, but for OpenPKG I can safely assume
> this as all(!) OpenPKG .spec files are enforced to follow the same
> strict syntax.
>

The lack of a state transition back to preamble parsing is
one of several major flaws in the rpmbuild spec file parser. Another,
related, flaw is the lack of section end marker, the next section
marker closes the previous section marker.

(aside) Should I attempt a '%}" or just carefully walk away from the  
mess?

FInally, the scoping of %if statements across section markers is sheer  
lunacy.
Its quite possible to write a spec file that conditionally appends  
%changelog
to %install dependent on what string is stored in /etc/rpm/platform.  
Not good.

>> Perhaps a better longer term
>> implementation would be to create syntax and macro primitive that  
>> forces
>> information into
>> the preamble from deeper within spec file section parsing. E.g.  
>> mumble
>> mumble
>>    %{preamble:Environment: %(...)}
>> which could then be expanded anywhere without the clunkiness of
>> overloading %description.
>
> Yes, such a feature would be great. Also great would be the  
> possibility
> to override a tag like "Release:" with a second one (whose value
> is usually calculated on the original one). For instance I would
> like to append a token to "Release:" in case *.org/*.rej files are
> autommatically picked up by a macro (see my other mail for this
> functionality).
>

I've offered such functionality for Release: rather than the  
uselessness (mho)  of policy
dictated %{?disttag} appending in the past, perfectly willing to try  
again.

>>>   local keyvalue = rpm.expand( \
>>>       "%(%{l_rpm} -qa --qf " .. \
>>>       "'\\\\[\\"%%{name}-%%{version}-%%{release}\\"\\\\] =" .. \
>>>       " %%|environment?{%%{environment}}:{\\\\{\\\\}}|,')" \
>>>   ) \
>>>   loadstring("environment = { " .. keyvalue .. "}")() \
>>>   local debug =
>>> rpm.expand("%{?__environment_debug}%{!?__environment_debug:no}") \
>>>   if debug == "yes" then \
>>>       io.stdout:write("Environment(original): " ..
>>> util.dump_object(environment, false) .. "\\n") \
>>>   end
>>>   \
>>
>> The lua binding design is slightly inverted here. You are invoking  
>> rpm
>> through %(...)
>> macros to do headerSprintf() call through rpm --query mostly  
>> because lua
>> is at the rpmio layer, while headerSprintf() is one layer above at  
>> the
>> rpmdb
>> layer.
>>
>> Perhaps a lua method through callback for headerSprintf() call  
>> directly
>> would be cleaner
>> and more useful rpmlua implementation.
>
> Well, yes, that's what practiicing those things shows up. It was the
> only possibility with the current implemetation. Multiple times I
> already wanted to have to possibility to do a real RPM header *query*
> directly from Lua. To have such a functionality would be great and  
> also
> would speed up things, too.
>

I've got an attempt to use SWIG to generate common bindings (including  
lua) to the two
most important functionalities (header tag access is one, rpmdb  
iterator is the other)
in rpm libraries around someplace. Mebbe 40% complete, but an approach  
through
SWIG is far more likely to be useful than the current hand-rolled per- 
language everyone
wants to do their own thing but noone wants to maintain if/when rpmlib  
changes. JMHO.
>> [...]]
>> All this filtering of gpg-pubkey everywhere using --query gets  
>> annoying.
>> Perhaps
>> generalizing the mire patterns currently implemented only as
>>    rpm -qa 'name=!gpg-pubkey-*'
>> for general --query and headerSprintf, not just rpm -qa, filtering is
>> finally perceived
>> as sufficiently useful to attempt.
>
> Yes, to be able to filter a query is a rather important feature
> one often requires, so it perhaps is certainly wise to think
> about a generic  solution to better support this.
>

I _THINK_ that adding a perl-like ~= selector like
     [%{filenames~=pattern]\n]'
could be wedged into the existing headerSprintf queryformat
parser in rpm-5.09. The code in rpmdb/hdrfmt.c is almost
readbale these days. Not true since originally implemented.

>> [...]
>> Nothing wrong with Environment:, but to my taste adding into existing
>> dependency metadata, rather than inventing Yet Another representation
>> of metadata linking packages, might be a more "natural"  
>> implementation.
>
> Yes, of course! If RPM would be able to track this information already
> internally in its existing meta-data would be preferred. I do not like
> the approach myself very much. But it at least the first time is a
> really *workable* solution...
>

One of the  reasons for adding HE_t was to focus on data, not package,  
representations.

There are already complicated attachments of dependencies to files  
using --filerequire
that are similar in structure to what you are doing with Environment:

I hasten to point out that I'm _NOT_ suggesting that you do  
Environment: like file dependencies
are done. Working around rpm's limited data types with legacy  
compatibility issues
ain't fun, nor is it necessary any more now that rpm is fork'ed.

todo++

73 de Jeff