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.

>> (aside) How about a generalization through arbitrary tags
>> added at install time?
>
> Yes, the reason why I had to code this in C and not (again) via some
> RPM macro and/or Lua hacking was the fact that arbitrary tags  
> currently
> exist during build-time only. If one could generate arbitrary install
> tags, say via an RPM "callback" macro expansion or whatever, this  
> would
> allow one to solve those issues, too.
>
>> (aside) What would also be needed is some primitives to
>> initialize if not found (like time(2) stamp here) in
>> previous header.
>
> Well, if you look at the code in detaol you will see that if no  
> previous
> header is found "installTime" is used as the fallback value and  
> this in
> turn is the time(3) value used for the "INSTALLTIME" tag. So, I think
> the initialization should be just fine.
>

There's some issues with timestamp jitter. Likely RPMTAG_INSTALLTID
value (which is per-transaction unique) is the best choice for default
missing value initialization of Install1st.

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.

>> The database hit with Yet Another transaction
>> flying around is, well, ick.
>
> Yes, _THIS_ is also _MY_ personal concern. I do not fully  
> understand the
> whole RPM internal processing, so I already feared the side-effects.
> But the current implementation was the only way I to achieve this. As
> you perfectly understand the RPM internals and hence certainly see  
> more
> possibilities, I would be very very happy if you could improve this
> piece of code for me.
>

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

Basically the only rule for hitting the database is -- like all db  
programming --
extract whatever and close the cursor as soon as possible. Dueling  
cursor
deadlocks are what must be avoided by the implementation.

>> 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++;

73 de Jeff