Distro upgrade policy

[Nemo157]

Currently it's documented that the images are built using Ubuntu 20.04, which is the most recent Ubuntu LTS. It would be good to have the upgrade policy for this clarified, is the intent to track Ubuntu LTS', or if someone put in the effort to do an upgrade would moving to newer non-LTS versions be acceptable?

This affects crates that rely on more modern system dependencies, e.g. rust-lang/docs.rs#1198, 20.04 is only shipping libcapstone3 while 21.04 has upgraded to libcapstone4. If we wait till the next LTS release then it's going to be another year till it's possible to build the documentation for falcon.

[Nemo157]

Glancing around @jyn514's comments on #32 and #71 assume tracking of the LTS releases.

[jyn514]

I kind of assumed LTS but given that the only thing we're doing is running sandboxed builds I would be ok with a more up to date version. @pietroalbini what do you think?

[pietroalbini]

The reason we're running LTS is to avoid having to bump the version every 6 months. If someone on the docs.rs team can commit to taking care of that I'm all for switching to a newer Ubuntu version, but I personally won't have the time to do so.

[imp]

Now that 22.04 LTS is out - perhaps it may be a good time to update?

[davidhewitt]

Also blocked Python 3.10 - #104 (comment)

[imp]

22.04.1 was recently released - what needs to be done to update the build env?

[Nemo157]

It looks like just updating the Dockerfiles and then upgrading/removing packages from the packages.txt that don't exist on the new version.

If someone gets a PR available I can do some testing of it on my local docs.rs instance. (Otherwise, if the package updates aren't too complex I might get around to looking at it myself at some point).

[imp]

I see that some packages have multiple versions installed (i.e. clang and clang-6.0) Any idea why is that needed ? Is it ok to only have latest (clang)?

[jyn514]

@imp here's what I did last time I upgraded the image: For each package that's been removed in the new version,

• See which commit it was added in.
  a) If it was present all the way back to the initial commit, it's likely just what was installed on our server at the time and you can safely remove it.
  b) If it was explicitly added in a PR to this repo, post here pinging the author of the PR, and asking whether they still need the package.