Keep older versions in OBS

[matpen]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

I have noticed that, whenever a new podman (or buildah) release comes out, the PPA is updated with the new one, but the old ones are removed. This makes it hard to pin versions in install scripts.

Is it possible to keep older versions in the PPA (at least a few back)?

Steps to reproduce the issue:

1. Install by pinning version: apt-get -yq install podman="1.5.0-2~ubuntu18.04~ppa5"

2. Notice that, after a release, the above code fails with
   E: Version '1.5.0-2~ubuntu18.04~ppa5' for 'podman' was not found

(Environment details omitted because not relevant)

[baude]

@lsm5 ptal

[lsm5]

Hi @matpen, just curious, do you know of any other PPAs that provide this? I don't think there's a trivial way to do this on PPA.

@baude @mheon once we have a new release, we stop supporting the older ones, yes?

[mheon]

Yeah, we don't generally do backports to older versions

[lsm5]

@matpen any reason you need to pin podman version?

[matpen]

Hi @matpen, just curious, do you know of any other PPAs that provide this? I don't think there's a trivial way to do this on PPA.

I think that it can be easily accomplished by using file names. At least this is what I see on the kernel ppa and gcc ppa.

For example, I used to install gcc 7 on Ubuntu 16.04 like this:

add-apt-repository ppa:ubuntu-toolchain-r/test
apt-get -yq update
apt-get -yq install gcc-7 g++-7

@matpen any reason you need to pin podman version?

When using podman in production, things might break on system update. For example, when upgrading from 1.5.0 to 1.5.1 the default pod hostname changed: I am making use of this information inside the containers, so the "old" config will not work with the "new" podman.

For this reason I prefer to keep podman at a defined version, which I tested on my development environment, until I have the time to upgrade.

@baude @mheon once we have a new release, we stop supporting the older ones, yes?

Unfortunately I have never setup a PPA myself, so I cannot provide direct experience. But one possible way to support both approaches could be to simply deploy as follows:

• publish one podman package, which is the "default" one and always points to the latest release;
• publish one "versioned copy" of the same filename;
• on the next release, replace the default, but keep the old versioned copy.

[lsm5]

Hi @matpen, just curious, do you know of any other PPAs that provide this? I don't think there's a trivial way to do this on PPA.

I think that it can be easily accomplished by using file names. At least this is what I see on the kernel ppa and gcc ppa.

For example, I used to install gcc 7 on Ubuntu 16.04 like this:

add-apt-repository ppa:ubuntu-toolchain-r/test
apt-get -yq update
apt-get -yq install gcc-7 g++-7

If upstream isn't supporting older releases, I'd rather not commit to this either.

There's another request to publish multiple PPAs where one has only the latest release, while the others have RCs/nightlies/hourlies. Perhaps you could use those (once published) to test upcoming versions?

When using podman in production, things might break on system update. For example, when upgrading from 1.5.0 to 1.5.1 the default pod hostname changed: I am making use of this information inside the containers, so the "old" config will not work with the "new" podman.

@mheon can correct me if I'm wrong, but the old behaviour was a bug. So, you should keep the new one.

[matpen]

If upstream isn't supporting older releases, I'd rather not commit to this either.

This has nothing to do with supporting old version. The requirement here is that an older version is still available through the convenience of the PPA, not that bugfixes are backported. In fact, this is exactly what should not happen (at least not without changing the version number).

There's another request to publish multiple PPAs where one has only the latest release, while the others have RCs/nightlies/hourlies. Perhaps you could use those (once published) to test upcoming versions?

This is not always an option: when the version is released, the PPAs are rotated, and it is not always possible to keep the production servers at the same pace.

the old behaviour was a bug. So, you should keep the new one.

In a perfect world, I would obviously always want the latest bugfree version. But in the real world, a new version will have incompatibilities. In this particular case the change, while definitely being an improvement, would break my containers.

Hi @matpen, just curious, do you know of any other PPAs that provide this? I don't think there's a trivial way to do this on PPA.

I just remembered that the docker project maintains exactly the envisioned setup:

[ ... ]
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
[ ... ]
sudo apt-get install docker-ce=<VERSION_STRING> docker-ce-cli=<VERSION_STRING> containerd.io

[lsm5]

Hmm, I think I can set this up, but quite likely won't be on the current launchpad ppa, but some other location where I have more control. I'll try and get back on this asap.

[afbjorklund]

I couldn't get any 1.5 nor 1.6 version to work properly on Ubuntu 16.04, so ended up having to rebuild v1.4.4 from source (since I had deleted the local .deb package)

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[rhatdan]

@lsm5 Any update on this?