PPA should not remove outdated packages needed as dependencies

[Martin Pool]

Suppose my ppa contains

  bzr 1.2
  bzr-gtk 1.2 (depends: bzr 1.2)

and I upload a new bzr 1.3, but have not yet uploaded bzr-gtk 1.3. The PPA will delete bzr 1.2. This leaves bzr-gtk uninstallable.

It would be better if it left old packages around either if they are depended-upon, or perhaps for several weeks regardless. Then at least apt would give people the choice to get 1.2 of both, or 1.3 without bzr-gtk.

See <https://lists.ubuntu.com/archives/bazaar/2008q1/039929.html>

[Celso Providelo (cprov)]

Hi Martin,

I can't keep this bug opened because your suggestion to keep both version of a given binary available (i.e. published) is unfeasible since apt will always force the installation of the latest version. The users would have to acknowledge and force the downgrade on every update and that's not good or easier to do, which is actually the same than "not to upgrade".

We can have a chat or a call about the current issue you are having in bzr-PPA and try to find out what we can do to mitigate them in the short-term.

[Mark Shuttleworth (sabdfl)]

Agreed, PPA's like the distro itself need to take responsibility for maintaining a consistent view across the archive. The distro would solve this by having a bzr1.2 and a bzr1.3 package, and *possibly having a bzr package which depends on the latest bzr1.x.

Mark

[Martin Pool (mbp)]

If the PPA user wants to have say bzr 1.2 and 1.3 available for an extended period of time, then giving them different names and having a metapackage point at just one of them is the standard way to do it.

However, for handling short transitions from one version of a related package to another the PPA approach seems worse than what is done in a standalone archive managed by apt-ftparchive.

[Martin Pool (mbp)]

I don't understand what you mean by "unfeasible".

Jelmer's assertion is that apt on the client can offer the user better options if it still has the old version of the package available. At any rate it can give them strictly more options. This seems to be how other apt archives are commonly run?

I agree that asking the user is suboptimal but it is better than making the package not installable at all.

[Martin Pool (mbp)]

Jelmer's post from that thread:

> > While PPA is building packages there still might be a (short) period of
> > time, where the packages are inconsistent. It would be a useful
> > launchpad feature to hold back packages until the desired dependencies
> > are fulfilled. But even for now it would be better to have an unusable
> > repository for five or ten minutes than for a few days.
> That's really just a workaround for a problem caused by PPA.
>
> APT can deal with multiple versions of packages just fine, but PPA
> removes older versions. For example, if the latest version of bzrtools
> available only works with bzr 1.2 but the latest bzr available was 1.3,
> apt would install bzr 1.2 and warn you it's not upgrading bzr.

[Martin Pool (mbp)]

lifeless also agrees that this is a bug.

[John A Meinel (jameinel)]

This is especially bad when releasing an rc before the next official release. For example, right now we have 1.3.1, and 1.4rc2. We should still allow people to install 1.3.1 since it is the last officially stable release. Further, it is likely that we do not have matching release candidates for 3rd party software present in the same archive. (bzrtools doesn't release a new version until 1.x-final is out, same for bzr-gtk)

[Martin Pool (mbp)]

On Tue, Apr 22, 2008 at 2:11 AM, John A Meinel <email address hidden> wrote:
> This is especially bad when releasing an rc before the next official
> release. For example, right now we have 1.3.1, and 1.4rc2. We should
> still allow people to install 1.3.1 since it is the last officially
> stable release.

I think for the use case of having two or more streams of releases,
stable and candidate, we do need either two PPAs or to be always
renaming the package in the way Mark outlines. In practice at the
moment that means we need to create a second team to own that PPA.

> Further, it is likely that we do not have matching
> release candidates for 3rd party software present in the same archive.
> (bzrtools doesn't release a new version until 1.x-final is out, same for
> bzr-gtk)

This is the real issue with this bug: within a single archive it's
pretty hard to exclude any possibility of things being uninstallable
for some time.

Maybe this seems to work for the distro because they have -proposed as
well as the main archive, and if things temporarily disappear from
-proposed the net effect is that the old one is still available from
the main archive?

--
Martin <http://launchpad.net/~mbp/>

[Christian Reis (kiko)]

I suggest for now using a second PPA if you really do require development packages to be made available. From what I've seen on this bug, this is not an easy thing to fix on the Soyuz/PPA side in any measure of the word (either components for PPAs, or some different policy for superseding or removal) so there's zero chance of it happening before August.

[Martin Pool (mbp)]

On Thu, Apr 24, 2008 at 1:37 AM, Christian Reis <email address hidden> wrote:
> I suggest for now using a second PPA if you really do require
> development packages to be made available.

OK, we can do that, and I think also we should relax the dependency.

Just to be clear, it has nothing to do with development packages, that
was just an example. Any situation where packages need to be in sync
but for reasons like failing to build would do.

--
Martin <http://launchpad.net/~mbp/>

[Celso Providelo (cprov)]

See bug #34086

[Martin Pool (mbp)]

Another way to tackle this, possibly easier, would be to allow multiple old versions to remain in the archive, as in bug 316818. Then you don't need to think about calculating the dependencies.