2011/2/14 Jeff Johnson <n3...@mac.com>: > > 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. it's an open list, just a matter of subscribing :)
-- Regards. Per Øyvind ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org