2011/7/12 Jeff Johnson <n3...@mac.com>: > 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 > a hack-o-round that then goes and loads multiple > headers repeatedly to try and adjust the set > returned by the original access to fit some desired > semantic goal. > > You need to figure a better *RE pattern, not whack in > lots of gunky code to "fix it somehow". Yes, I kinda suspected this certainly wasn't the most optimal way to solve this.. :|
The problem basically is that it's doing comparision of RPMTAG_NVRA between the installed packaged and the package to be installed, which will give us problems when only distepoch differs since RPMTAG_NVRA still isn't consistent with %___NVRA. ie. for: foo-1-1-mdv2011.0.x86_64 vs foo-1-1-mdv2012.0.x86_64, NVRA will be 'foo-1-1.x86_64' for both. So any good suggestions on performing the check on distepoch in addition without heavy drawbacks? Checking distepoch of the package to be installed is easy and fast enough with rpmteD(p), but any chance of providing distepoch with the keys returned by rpmdbMireApply on RPMTAG_NVRA in some way..? -- Regards, Per Øyvind ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
