Support proposed pocket in PPAs
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Triaged
|
Low
|
Unassigned | ||
Bug Description
Please support uploading to the proposed pocket of PPAs, and expose methods in the web interface and api to pocket-copy from proposed to release within a PPA.
My use case for this is:
I maintain several PPAs for mercurial, which has an arch-indep and an arch-specific package which must be the same version. If the i386 build (including the arch-indep package) and the other architectures builds do not publish simultaneously, the other architectures are uninstallable until the package versions come back in sync in future publishings.
If I could upload to the proposed pocket and simply choose to pocket-copy once all binaries were published, this would solve the problem.
Another use case which would be addressed would be people desiring to manually test built binaries before releasing them to general users of their PPAs.
I'm aware that this workflow can be emulated using two separate PPAs, but that has a couple of shortcomings:
1) Since separate PPAs don't share a pool/, ppa.launchpad.net needs to keep two copies of all the packages on disk.
2) If you follow a workflow of deleting packages from the staging PPA once they have been promoted, you can no longer re-use their .orig.tar.gz files for future uploads.
| Julian Edwards (julian-edwards) wrote | #1 |
| Changed in soyuz: | |
| importance: | Undecided → Low |
| status: | New → Triaged |
| tags: | added: feature |
| Max Bowsher (maxb) wrote | #2 |
| William Grant (wgrant) wrote | #3 |
On Monday 11 May 2009 01:10:14 Max Bowsher wrote:
> I'm aware that this workflow can be emulated using two separate PPAs, but
> that has a couple of shortcomings:
>
> 1) Since separate PPAs don't share a pool/, ppa.launchpad.net needs to
> keep two copies of all the packages on disk.
This isn't that big a problem for us.
> 2) If you follow a workflow of deleting packages from the staging PPA
> once they have been promoted, you can no longer re-use their
> .orig.tar.gz files for future uploads.
Why not just leave them to supersede naturally?
Ultimately, this is probably a useful change to make, but it would be really confusing to newbies. Since you have this workaround, I'll mark this as low priority for the moment, but we should continue the conversation and decide on how to make this work for all types of users.