Intra-archive copying of a source with a failed build may leave that source uncopyable

Bug #527551 reported by William Grant on 2010-02-25
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Launchpad itself

Bug Description

If a build fails in one series, and then the source is copied with binaries to another, the new series will gain a build to replace the previous failure. If this new build succeeds, it obscurely becomes impossible to copy from the original series, as it is missing the binary from the second series. Ideally this situation would be avoided somehow, but making the error message ("binaries conflicting with the existing ones") more obvious would help.

Julian Edwards (julian-edwards) wrote :

Interesting. I'm not sure what's best to do here. We could prevent copying with binaries if any are failed, but that might prevent legitimate copies. Or, we could just fix the error message.

Changed in soyuz:
status: New → Triaged
importance: Undecided → Low
tags: added: soyuz-core
William Grant (wgrant) wrote :

This also occurs after copying source and binaries from Lucid to Karmic -- a new lpia build is created, making the Lucid source uncopyable.

Julian Edwards (julian-edwards) wrote :

So this only occurs because of that crazy packagecopier superset check. The copy action seems like a legitimate thing to want to do.

Changed in launchpad:
importance: Low → High
Max Bowsher (maxb) wrote :

I seem to be unable to re-copy python2.5 originally copied from the primary archive into a PPA, again to a different series within the same PPA - - with a spurious conflicting binaries error. Uncertain if it's entirely the same, but it feels similar.

William Grant (wgrant) on 2012-10-15
tags: added: package-copies
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers