Comment 3 for bug 536641

I prepared and ran the following on staging:

https://pastebin.canonical.com/30713/

which deletes the SPR 618325 and it's corresponding builds, source publishing history, packagediffs etc., (results here https://pastebin.canonical.com/30748/). This fixes the one issue of the two SPR's, but reveals another.

Now viewing the source package in lucid shows only the one release - great:
https://edge.launchpad.net/ubuntu/lucid/+source/sun-java6

But clicking on the release https://staging.launchpad.net/ubuntu/+source/sun-java6/6.18-2 now shows a different oops, and as far as I can tell this is unrelated to the issue of the two SPRs.

DistroSeriesBinaryPackage.cache assumes that there will only be *one* DistroSeriesPackageCache item for each binary package name in lucid, for *all* distro archives.

I say unrelated to the duplicate SPR issue because the SPR that we're deleting didn't have any binaries to cache.

Now given that this package used to be published in multiverse (and would have had DistroSeriesPackageCache entries for its binaries related to the primary archive), and now it is published in partner, and no doubt has DistroSeriesPackageCache entries for its binaries related to the partner archive (as DistroSeries.updatePackageCache() creates one if one doesn't exist in the given archive), I'm assuming we need to either:

1. Change DSBP.cache() to use selectFirst() instead of selectOne() so it is more tolerant of this,
2. Ensure DistroSeries.updatePackageCache() doesn't create a new cache item for a distro archive if one already exists in another distro archive,
3. Delete the existing DistroSeriesPackageCache entries for all the related binary package names in main (sounds scary)?

or all of the above? Personally I'm keen for a CP of (1) with (2) in devel. I'll wait for a second opinion before going any further in case I've confused something above, but all I can say is, it'll be nice when partner is just another PPA.