Can't re-upload a package with a different src tarball after deletion in PPA

Ideally orig.tar.gz files are an exact match for some file released by upstream. Unfortunately, not all upstreams make releases in this manner, or make available distribution tarballs in a format accepted by Soyuz. In these cases, the orig.tar.gz file must be created by the packager, often through the use of a get-orig-source rule in debian/rules. If there is a bug discovered in this rule, it may be that the created orig.tar.gz file does not accurately represent the claimed version of the software. One example that can create this would be when upstream makes releases by tagging a VCS, and the packager pulls that branch: it may be that the incorrect branch is pulled accidentally, corrupting the orig.tar.gz.

Conventionally, an orig.tar.gz file is considered to be an inviolable artifact, and ideally every orig.tar.gz available from every source matches perfectly. This helps to give confidence to users that they have a given version of the upstream software, and further eases the comparison of patches between distributions as part of coordinated development towards common goals.

The current implementation enforces this convention, which is a very good thing from the point of view of end users, and those seeking to compare different packagings of the same package or reviewing items from a PPA to determine suitability of application for other purposes. Unfortunately, enforcing this limits the suitability of PPAs for those who are new to packaging, or may be more likely to make small mistakes when building tarballs. While the version can be increased in a PPA (e.g. 1.2.3 -> 1.2.3+repack -> 1.2.3+repack2, etc.), the end result package may not be suitable for introduction into larger archives (e.g. Ubuntu), without reversioning (i.e. 1.2.3). As a result, users who have the +repack versions from the PPA will not receive the official version (as 1.2.3+repack-0ubuntu1~ppa > 1.2.3-0ubuntu2). This can be worked around by using special upstream versions for PPAs (e.g. 1.2.3~ppa4-0buntu1~ppa2), but such a package is then unsuitable for either easy comparison to other packaging of the same upstream version or for introduction into wider archives.

Changing the current behaviour to allow deletion of both the content and the blacklisting of a given orig.tar.gz file avoids the problems and workarounds described above, but defeats the goal of having a trusted orig.tar.gz that is identical in all locations, complicates the task of identifying patches applied in PPA revisions, and may result in coordination issues for teams, where two members may have the identically named orig.tar.gz with different contents (but against which the same diff.gz safely applies), and perhaps inadvertantly change the behaviour of the package by repeatd uploads from each source (perhaps complicated when the packaging alone is in VCS, and the team members are not downloading the tar.gz each time).

After avoiding this issue for quite a while, I think a decision was made regarding the consistency of the history stored for PPA.

Allowing upload of different contents under the same filename is utterly bad for history consistency, I assume there is not doubt about it and the more PPAs grow (including signed repositories) the more we have to choose the path for consistency instead forgiven to use mistakes.

There are proper ways around upstream problems (or even user mistakes, for instance patching the orig tarball, suffixing the version, etc) in a way users will continue to benefit of proper history and source & binary within PPAs.

Note that I'm not saying that getting around diverging tarballs or broken version are easy, neither that they are a desirable thing. That's why it's important to think about a safe versioning path when you are maintaining a source that is available to the world.