Open CyrilBrulebois opened 1 month ago
Just to be on the safe side, maybe trigger deletion with a delay.
For example, when the PPA moves from 16.3.3 to 16.4.8, what gets deleted is not all 16.4. versions, but everything below 16.3.3 (maybe strictly, i.e. keeping 16.3.3 itself): if regressions are spotted once 16.4.8 is user-visible, we can ask users to try 16.4. versions to chase down when it was introduced.
Another way to approach this is to avoid having any heuristics in deb-frido
, and to rely on the oldest (lowest) version found in the PPA: we tend to keep a few versions around (currently without any explicit expiry policy), so forgetting everything on our end that's lower than (or equal to) the oldest version there should do the trick.
At the moment, packages get added into the PPA but they are never cleaned up.
It would probably make sense to have some time-based and/or version-based expiry. Since the machine gets a backup every day, we probably don't need to keep anything on a time-based fashion: we can always fish out old packages from backups if needed.
Regarding version-based expiry: when metadata indicate the PTS PPA gets a new version, we should be able to remove anything below that version (maybe going through the
Packages
file, filtering based on theVersion
field, then using theFilename
one to remove-if-still-present).A possible approach would be to remove files from the PPA during the metadata check. Then either wait for a build to happen so that the PPA gets indexed and published again, propagating the removal to the remote. Or extract indexing/pushing code from the
builds
module and make it reusable. The former seems easier even if the removal is only local until the next (successful) build.In both cases, the sync needs to account for file deletions, so
rsync
needs to get a--delete
option in the config file.