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

Reply via email to