"same version already has published binaries in the destination archive" error when copying and rebuilding between series in a PPA

confirming, I ran into this issue myself

Hi Chris,

You are right, we could do better in this case. For the record, the fact that we don't rebuild sources in the same location isn't exactly a limitation, it's a feature that avoids messing the PPA clients systems.

I totally agree with your first suggestion we can use JS on the client side for blocking selections of 'This PPA' and 'rebuild sources' and render a more specific error message. Also, instead of rendering the specific error message for every copy candidate we could easily render a generic 'you cannot rebuild sources within the same archive' error.

I have a complementary suggestion for having more helpful error messages without cluttering the current UI. We can point users to a wiki page in help.launchpad.net where copy errors are verbosely explained, similarly to what we already do for source upload errors.

Let me know what you think.

> the fact that we don't rebuild sources in the same location isn't exactly
> a limitation, it's a feature that avoids messing the PPA clients systems.

I don't see how this makes sense, as you always add only one series to one sources.list line.

It would seem a logical request to build the same source package for different series; I even saw a script on the web that changes series in the debian/changelog and uploads otherwise same source tarball for each series - which is apparently possible for the PPA to handle, but the fact of uploading almost same many times is suboptimal both {bandwidth,storage}-wise and for usability.

In fact, what is the suggested workaround? If I create new ppa (with the same owner) for the copied packages, is that better (for launchpad) than uploading multiple times?

The core problem is that you can't rebuild the same version more than once in a pool-based repository. You'd need to upload different builds (from each series) of the same binary version, and there's nowhere to put them because the indexes can only refer to one file in the pool for each version.

If you want to do it, the only solution is to bump the version. Ubuntu does this by appending ~hardy or ~intrepid, for example, to the version of the package.

> If I create new ppa (with the same owner) for the copied packages, is that better (for launchpad) than uploading multiple times?

Not really, it means you would need to tell people about different sources.list entries if they upgrade. The preferred way of doing this is, in this order:

 * copy to the new series, and include binaries.
 * upload a new version specifically for the series if you *have* to rebuild

It would be nice with the posibility to rename the destination version during to copy and rebuild.

E.g. prog-1.2.1 -> prog-1.2.1~lucid0

+1 for the suggestion in #5. It would save a lot of trouble to be able to copy & rebuild for another series without having to upload sources again. For example, I could get a karmic build right now for a package that's already built for lucid, rather than having to wait until I get home (where my sources and private key live). If a version change is all that's required to work around the limitation, making that possible via the PPA web UI seems like a really handy feature.

Another +1 for the suggestion in #5. This would make supporting multiple distro versions far easier. In fact, I would think this would be one of the primary use-cases for Launchpad's copy package feature.

Before that's possible, we would need to fix bug 245594. Bug 235064 is also related.

+1 for suggestion #5. Maintaining multiple versions is a real pain.

Where is the code that this feature would be added to, to automatically append ~release0 to copied versions?

I just ran into exactly the same problem. I would like to add a version of my package for trusty to my PPA. It does require a rebuild but no changes to the source code. So I assumed that the copy function would simply change the ~precise to ~trusty in the copy process and rebuild. Unfortunately it doesn't work as such, so it seems like I'll have to upload a new tarball (and try to remember how I did this in the first place). Having this feature work as `expected' would save a lot of time.

+1 on this issue

+1 for the suggestion in #5. I have run into situations where I want to build the same package for precise and trusty, but I cannot use the copy package tool because of this error

+1 for #5
I just ran into it as well

Why is this bug open for so long? The suggested copy-bump-rebuild option seems straight-forward to me, and from my end seems like an important requirement to *not* blow off for 7 years. So far this "small" bit of Ubuntu development process (for me anyway) has been slow and painful just get one version built. I will probably just spend most of my time on Gentoo instead, at least until this "interface" gets better. In fact, it's easier to build the whole thing with Yocto, so there ya go...

Let's repeat that for clarity: horribly broken developer workflow will just keep putting people off. If you want to attract more users (of the ppa builder itself) then you need to fix these bugs. Thanks.

+1 hitting this today.

+1

+1

+1

+1

I have created a second PPA as a destination & series which are named with the Ubuntu release targeted then rebuild the copied source.

+1

I just added 2 more architectures but it doesn't allow me to recompile because i386 and amd64 are already there. Of course they are! can't you just omit them and compile the new ones? Is it so hard that can't be addressed in almost 10 yr?

+1

+1

+1

+1

+1

+1