Do an apt-get update before installing deb dependencies, if any

[sbidoul]

In sbidoul/runboat#48 we noticed that doing an apt-get install could fail due to package information being outdated.

We do an apt-get update in the Dockerfile. Even though we rebuild the images nightly, due to layer caching, there can be a long delay (up to 2 weeks IIRC) between the apt-get update and apt-get install.

The question I have is the following. Is the problem we had in sbidoul/runboat#48 a one-off incident or could it become prevalent ? In which case we'll need to do something about the installation of addons deb dependencies here and here.

When we look at http://archive.ubuntu.com/ubuntu/pool/main/r/rsync/ we can see that a lot of versions are there, which tend to imply that published version remain available "forever". http://archive.ubuntu.com/ubuntu/pool/main/r/rsync/rsync_3.1.3-8ubuntu0.1_amd64.deb is however absent.

So I suspect it was published then removed and we just played bad luck as we cached an apt index that still included it.

I'm not sure about this explanation and if we should do something about it. If there are people around with deb packaging expertise who could shed light on this it would be very welcome. @gurneyalex maybe ?

[JuanDCG]

I'm not an expert about deb packaging neither Runbot or the Runboat that you want build with kubernetes technologies.

From my point of view, your root mistake cause is continue using deb packages inside containers.

Your approach to build Odoo CI with k8s (CDeployment) is well raised, but I propose change all possible deb dependencies with Git dependencies.

Nowadays, in kubernetes environment, the best approach is work with GitOps workflow.

I hope give you another point of view.

[zeroheure]

One easy to run solution is to add an apt cache proxy like apt-cacher-ng. Then you will not update the proxy if packages are not available. Additionaly it will run faster and with less bandwith.

[gurneyalex]

in a docker container, you cannot rely on an apt update happening at build time of the image: 1. typically, to have a smaller image, you will get an apt-get clean in the Dockerfile and 2. there may be a new version of the tool you want to install pushed in the repository between the building of the image and the running of the container (and these are typically secutrity updates.

So if you need to install things at container runtime, you need to apt-get update (you may want to do this lazily, i.e. try to install and if you fail, apt update and try again), but I think a better approach is to clean up the apt cache in the base docker image and systematically update in the container.

[gurneyalex]

@zeroheure yes but no. The goal here is to test using the versions of dependencies available in stable distributions, with security patches applied.

[fcayre]

I had the same problem last week with another Ubuntu package required by my tests. I think this happens when a package has a security vulnerability: it is then removed to avoid being installed and cause a security hole on the host, just because of an outdated apt database. I think it is a good practice to always apt update before apt install.

[sbidoul]

The apt update needs to be done around here. We need to do it only if there any external dependencies to install, for performance reasons.