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.

>> [...]
>> %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.

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

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

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

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

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com