----- "Will Woods" wwoods@redhat.com wrote:
No, because apparently PackageKit-0.5.6-1.fc12 is already public in f12-updates. The test is supposed to check things that land in dist-f12-updates-candidate (e.g. new builds) against whatever is currently public.
So somehow PackageKit-0.5.6-1.fc12 appeared in updates-candidate despite it already being in the updates repo? I wonder how that happened.
I have dug into that issue and it's little more complicated. It doesn't matter if James started the test manually or not. Generally there is one use case where rpmguard compares the new package with itself. It is when the updated package moves to official repositories before the rpmguard test is performed.
Usually it goes like this: 1. Maintainer builds a new package, it's tagged as -updates-candidate. 2. AutoQA detects the updated package and using its library rpmguard looks for the most recent package in stable, -updates and -updates-testing. 3. Rpmguard compares new package from 1) with older package from 2). 4. Some time later a package from 1) is re-tagged as -updates or -updates-testing.
The problem arises when step 4) is between steps 1) and 2), ie. when maintainer moves his new package from -updates-candidate to either -updates or -updates-testing too soon. If AutoQA watcher is run only after that, then obviously the package version from 1) and from 2) are equal. And rpmguard simply compares them.
So that's the explanation of the situation. Of course I can modify rpmguard to simply skip checking of identical packages, but that does not solve the problem of that particular package not being checked against the older version. I will cover possible solutions in a future email, I have to play with it a little more.
One more thing:
Previous package for dist-f12-updates was PackageKit-0.5.6-1.fc12 Previous package for dist-f12-updates was PackageKit-0.5.6-1.fc12 Previous package for dist-f12 was PackageKit-0.5.4-0.1.20091029git.fc12
This is not weird at all. It just means that there is no PackageKit in dist-f12-updates-testing, and according to tag inheritance [1] it found the most recent PackageKit in dist-f12-updates (which is obviously the same result as when checking the dist-f12-updates tag itself), hence the same line.
If there hadn't been any PackageKit updates since F12 release, there would've been three identical lines mentioning dist-12 tag.