Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ transaction.c

2011-07-13 Thread Jeff Johnson
On Jul 13, 2011, at 2:56 PM, Per Øyvind Karlsen wrote: >> >> >> So back up a bit, look at the code path on which this bullshit >> test is being performed, think a bit, and just rip the entire >> test out. > Yeah, not disagreeing with you on that one.. :) > Good. Then haul out the trash please

Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ transaction.c

2011-07-13 Thread Per Øyvind Karlsen
2011/7/13 Jeff Johnson : > > On Jul 13, 2011, at 1:54 PM, Per Øyvind Karlsen wrote: > >>> >>> >>> Passing keys Somewhere Else Instead isn't needed either: rpmdbMireApply() >>> is perfectly capable of being used intelligently, to perform a bullshit >>> test that isn't necessary at all, however you w

Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ transaction.c

2011-07-13 Thread Jeff Johnson
On Jul 13, 2011, at 1:54 PM, Per Øyvind Karlsen wrote: >> >> >> Passing keys Somewhere Else Instead isn't needed either: rpmdbMireApply() >> is perfectly capable of being used intelligently, to perform a bullshit >> test that isn't necessary at all, however you wish. > > Would this be more acc

Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ transaction.c

2011-07-13 Thread Per Øyvind Karlsen
2011/7/12 Jeff Johnson : > > On Jul 12, 2011, at 8:21 AM, Per Øyvind Karlsen wrote: > >> 2011/7/12 Jeff Johnson : >>> This isn't at all the right approach because >>> its doesn't scale. >>> >>> You have changed a single high performing rpmdb >>> access that applies patterns to keys only, and added

Re: Distepoch & "identification" (was Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ transaction.c)

2011-07-13 Thread Per Øyvind Karlsen
2011/7/12 Jeff Johnson : > Lemme split this into 2 threads to try to address > two twisted issues properly. The other thread will be >        Transaction sanity checks > > On Jul 12, 2011, at 8:48 AM, Jeff Johnson wrote: > You need to figure a better *RE pattern, not whack in lots of