Combining async copying and deletion loses overrides

Bug #1152149 reported by Colin Watson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
High
Colin Watson

Bug Description

The current Ubuntu automation for copying packages from the PROPOSED pocket to the RELEASE pocket after they've passed automated tests goes something like this:

  archive.copyPackage(from_pocket="Proposed", to_pocket="Release")
  archive.getPublishedSources(pocket="Proposed").requestDeletion()

Doing the copy and the delete in the same run greatly simplifies the code (since this is in a script launched by the generic proposed-migration "britney" code, which doesn't really understand Launchpad itself), and it mostly works. However, the gotcha is that the copy is asynchronous, and so often happens after the synchronous delete. We've observed that this means that overrides for packages not yet in the RELEASE pocket are re-applied according to the "unknown" policy, so in practice what happens is that binaries tend to fall out to universe even if we overrode them to main when accepting them into the PROPOSED pocket. This is one of the principal causes of Ubuntu daily image build failures today.

I think the simplest fix will be to check for overrides in DELETED publications too. This should not be a significant extra query load (deleted publications are comparatively rare) and IMO it makes sense in general to use a previous publication as a default even if it was deleted. The one thing I can see that we need to be careful of is that this shouldn't change the new vs. unapproved behaviour for copies.

Related branches

Revision history for this message
Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-needstesting
Changed in launchpad:
status: In Progress → Fix Committed
Colin Watson (cjwatson)
tags: added: qa-ok
removed: qa-needstesting
Colin Watson (cjwatson)
Changed in launchpad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.