Cannot replace incorrect files from PPA, ever

Bug #491165 reported by Jason Heeris
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Won't Fix

Bug Description

This concerns the PPA at: and question #92507 [1].

1. Upload incorrect orig tarball.
2. Realise you've done this.
3. Request deletion of bad package.
4. Try to upload correct package.
5. Upload is rejected, initially because the orig tarball still exists, eventually because the package is already thought to be in Ubuntu.

The package and associated files are *not* there, however. This makes it impossible to use the workaround of using the incorrectly uploaded tarball for subsequent uploads; furthermore, if the tarball is wrong I wouldn't want to do this anyway.

The workaround given in[1] is to upload another "wrong" package, and then upload a third.

Seriously, I think file deletion is an *essential* part of repository management and quality control. A single typo in a changelog can cause an incorrect tarball to be built, and it's only when subsequent uploads are rejected for having the wrong hash that a developer might realise this. Having to upload deliberately broken packages just introduces further risks (to users) when trying to fix it.

(Also, if "request deletion" does not in fact delete the packages in question, why is it labelled that way?)


Revision history for this message
Curtis Hovey (sinzui) wrote :

The correct solution is to increment the version of the deb because users who may have installed it need an immediate update. So, the correct solution is to supersede the wrong version, and PPAs already do this.

affects: launchpad → soyuz
Changed in soyuz:
status: New → Invalid
Revision history for this message
Jason Heeris (detly) wrote :

This bug does not concern packaging information — the problem occurs when only the orig tarball has been uploaded. A user cannot install an orig tarball on it's own, and your reply seems to make no sense.

Please read the report again, it concerns an incorrect upload of the UPSTREAM archive, nothing to do with deb packaging information.

The resolution to this is actually in the "question"[1] I asked about the same. I appended "+actual" to the orig tarball and hacked around it in the packaging. As I said there: I really think you should change the wording of the "Request Deletion" link, since it seems to have nothing to do with deletion, just "hiding" (or possibly, "deletion from index" or somesuch), and mention that the file is not, in fact, deleted.


Revision history for this message
Julian Edwards (julian-edwards) wrote :

The page could refer to the help here:

Which explains more about deleting.

Changed in soyuz:
importance: Undecided → Low
status: Invalid → Triaged
Revision history for this message
Julian Edwards (julian-edwards) wrote :

FTR, it's not "hiding" anything, it does delete all files. However, it remembers what versions of files you uploaded so that anyone who's been using the PPA doesn't get a nasty error from apt when downloading the "same" file with a different checksum.

tags: added: ppa trivial
Revision history for this message
Julian Edwards (julian-edwards) wrote :

Until very recently we had a bug that allowed re-uploading of files that had been previously uploaded, which causes havoc across the PPA system particularly when people copy packages around.

We will never allow multiple copies of the same file to co-exist with different contents, it's simply far too confusing for everyone involved.

However, once the file has expired in the librarian, you'll be able to re-upload it. This is a bit of a bug but you can make use of it for now. The real solution is to upload an orig file that's slightly renamed.

Changed in launchpad:
status: Triaged → Won't Fix
tags: added: bugjam2010
removed: trivial
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions