Release process: adapt garbage collection of IUKs to the single SquashFS diff...
Release process: adapt garbage collection of IUKs to the single SquashFS diff upgrade scheme (#15284) In the single SquashFS diff upgrade scheme, we'll generate and publish many more IUKs and will need to delete obsolete ones more aggressively. The good news is that we have a much better criterion for that than the age of an IUK: since every new release will have IUKs that upgrade to this new release from any older version that has the same "X" as the new release in "version X.Y", we know it follows that any IUK that upgrades to anything but the version that was just released is obsolete and can go away. So essentially, at any point in time, our mirrors will store the set of IUKs that upgrade to the current version of Tails, and that's it. The only exceptions are: - IUKs v1, that we'll need to garbage collect manually at a well chosen time; this is a one-time cleanup operation and does not seem worth automating; - In the release process, between the time the IUKs for the new release are uploaded, and the time when the RM goes this this post-release cleanup step, our mirrors will store 2 sets of IUKs: those that upgrade to the previous version, and those that upgrade to the new one.