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.
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. getSourcesForDe letion( ) 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.