On Feb 13, 2011, at 10:15 PM, Jeff Johnson wrote: > > Hmm the rpmiPrune() just above psm.c:1666 might need to > looked at ... until yesterday it really dinna matter whether > %trigger's worked beyond the toy test cases I originally > wrote when implementing. Its probably ok, rpmmiPrune() is used > heavily in lib/depends.c. But rpmmiPrune() affects rpmmiCount() > in non-trivial ways now that there's no array of "join keys" > to prune. >
Nah its not okay, the trigger counts are likely fubar for any complex (i.e. more than 1) trigger firing based on patterns. The intent with rpmmiPrune() was to avoid already processed headers when headerLoad() was far more expensive an operation than it is in "RPM ACID". But rpmmiPrune() and rpmmiCount() are going to interact in some very complex ways. Since headerLoad() is rather lightweight, a simple continue within the iterator can be done instead for headers that have already been processed. Make sense? I'll get this fixed in the next couple of days (took 2 days to rsync 2011.0 packages this weekend, sigh. But I should be able to keep up w Cooker because of rsync more easily). And no I'm not subscribed to <maintainers@ ... >, my reply bounced. 73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
