On Wed, Jan 30, 2008, Jeff Johnson wrote:

> On Jan 30, 2008, at 1:59 PM, Ralf S. Engelschall wrote:
>> On Wed, Jan 30, 2008, Jeff Johnson wrote:
>>
>>> Eeek!
>>
>> Yes, I expected your reaction... ;-)
>>
>>> (aside) There's a need to carry information forward persistently
>>> in headers. Consider packages installed with --relocate,
>>> RPMTAG_INSTALLTIME1ST has similar persistence
>>> needs. There's also flink/blink upgrade chains that persistently
>>> carry info.
>>
>> Can you go into more detail on this, Jeff? I don't think
>> I already fully get the point.
>
> OK. Take the following as example, getting a "natural"
> feel to names and syntax always takes polishing ...
>
> Assume
> 	%_install_persistent_tags	Install1st
> That establishes the necessary "Install1st" name string.
>
> Then rpmtsAddInstallElement() can gather tag items
> from old Header for adding persistently.
>
> The new need is how to initialize if the tag doesn't
> exist. The quick syntax hack for, say, time stamps would be
> 	%_install_persistent_tags	Install1st(timestamp)
> and then attach time(2) (or better) as default initial value.
>
> The arg state necessary for --relocate could be buried
> in a "...(relocate)" quicky syntax. The flink/blink chaining
> perhaps too.
>
> Alternatively, the default initial value can be hidden in
> a conventionally named initializer macro expansion.

Hmmm... ok, this then would allow to make some tags persistent, but I
think for a general solution it is still a little bit too weak. The
"arbitrary tags" from build-time are great as one can generate whatever
values and from whatever sources one wishes. For "abitrary tags" during
install time I would expect something more flexible. Perhaps...

On package installation for each tag named <tag-name> the macro
"%{_install_tag_filter_<tag-name> <tag-value>}" is macro-expanded to
<query> and then taken as a RPMDB queryformat string and executed as in
"rpm -qa --qf '<query>'". The result has to be a list of tag name/value
pairs which as a result are stored into the RPMDB: "<tag-name>
<tag-value>[ <tag-name> <tag-value>[ ...]". To allow spaces in values
one has to at least support escaping characters via "\<character>".

The "first install time" then could be implemented e.g. like this:

%_install_tag_filter_INSTALLTIME() \
    INSTALLTIME %1 \
    INSTALLTIME1ST %%|INSTALLTIME1ST?{%%{INSTALLTIME1ST}}:{%1}|

To allow one to create new tags from scratch, RPM additionally would
always expand and process the filter "%{__install_tag_filter_NONE}".
This allows e.g.:

%_install_tag_filter_NONE() \
    FOO My\ Lovely\ Custom\ Tag

And because the values are macro-expanded before they are
treated as query string one even could do crazy things like:

%_install_tag_filter_FOO() \
    FOO %{lua: print(util.rsubst(rpm.expand("%1"), "[ \t]+", "")) }

Which would during installation would remove all whitespaces from the
value of tag FOO.

> [...]
> Note also that -- no matter what time(2) value is used -- if yer
> clocks are wrong when first stamping, you _WILL_ have persistent
> forevermore
> confusion propagating RPMTAG_INSTALLTIME1st forward.

Good point. That's certainly true. To fix one would have to completely
erase the package and reinstall from scratch. But that's the price for
having a broken clock ;-)

> [...]
> My guess is that yr implementation would have worked. Just, well,
> overly complicated.

Yes, the basic tests worked for me.
But until now I've not done any in-depth testing, of course.

>>> The previous time stamp
>>> could be extracted from previous header in
>>> rpmtsAddInstallElement(), added to rpmte carrier,
>>> retrieved and readded to new header without the
>>> database hit in lib/psm.c
>>
>> Could you be so kind and quickly implement this for me, Jeff? Just
>> change the code, please. You know the internals of RPM a lot better
>> than me and hence can make this stuff more correct already in the first
>> place. I want to avoid doing ping-pong commits just to get this better
>> myself.
>
> todo++;

Many thanks, Jeff!
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com