Tests for package downgrades

[Vincinator]

What would you like to be added:

As a Maintainer, I need tests that verify that no unintentional package downgrades are made when creating a new minor Version.

Why is this needed:

Without this safeguard, package downgrades could introduce breaking changes noticed by customers before us.

[fwilhe]

In Garden Linux 1592.7, it looks like libxml2 was 'downgraded' unintentionally, from version 2.12.7+dfsg-3gardenlinux0 to version 2.9.14+dfsg-1gl2+bp1592 (notice the minor number got smaller, from 12 to 9).

In my view, this should not happen in general. Version numbers are supposed to be increasing monotonous, meaning a newer Version of Garden Linux must have the same or a higher version of any of the packages, but must never have a smaller number. This might for example be a problem if a client used any new feature introduced in the 2.12 minor version.

It looks like in this case there is no bigger problem, but it is also easy to imagine that by accident a Garden Linux maintainer might import a package built for Garden Linux 1443 into a patch release for 1592. I think this has not happened so far, but also I don't believe we have safeguards against this.

So, in my view, we need to test for at least two things:

• For any package version y in the newer Garden Linux release, y MUST be >= the version x from the previous Garden Linux patch release
• For any package version in Garden Linux Version X (for example 1592), the version number MUST NOT contain bp1443 (which might happen by accident)

[Vincinator]

Suggestion:

1. We make Pull Requests mandatory for changes to gardenlinux/repo rel-* branches
2. We add a github action that checks the diff, and fails if a downgrade happens (or if a wrong version suffix appears)

Pros:

• Maintainer can manually override if this new downgrade-check fails
• PR review process for production apt repo

[fwilhe]

PR review process for production apt repo

that sounds very good

I do worry a bit about if the whole team agrees on this mode, we need to align on this and have buy-in from all team members, otherwise this might result in unexpected things.