Deleted sources can leave binaries hanging around forever

[Julian Edwards]

In the case where someone deletes a source before the binaries are built and accepted (and thus get publications), the binaries will be orphaned causing the source to never get scheduled for deletion.

[Julian Edwards (julian-edwards)]

This has performance implications for the publisher, because it picks up the archives with pending deletions each time it runs.

[Julian Edwards (julian-edwards)]

This query shows affected publications.

select spph.id from archive, sourcepackagepublishinghistory as spph
where
        archive.purpose=2 and
        spph.archive = archive.id and
        spph.scheduleddeletiondate is null and
        spph.datepublished is null and
        spph.status in (1,4)

[Julian Edwards (julian-edwards)]

For cleaning up I think it's safe, where a source was deleted without ever being published, to mark all its binaries as deleted and let the domination DTRT with source and binary.

The +delete-packages forum currently carries on presenting sources for deletion if it sees that there are still published binaries. This is a little counter-intuitive since the package appears as "deleted" and there's no explicit mention of the binary state, so you're left wondering what's up.

If we fix IArchive.getSourcesForDeletion() to not return any source that has a build in progress, we should be able to avoid this. We can delete the source if the build is not yet active and the buildd-manager would supersede the build, but I need to think about race conditions there where we would mark the source deleted at the same moment as the build is dispatched.

[Julian Edwards (julian-edwards)]

Wgrant has pointed out that a better solution will be to drop binaries as soon as we get them from the builders if the source was deleted or superseded before the build finished.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r12064 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12064>.