Add an option for skopeo sync to delete in the destination what's missing from the source

[ferferga]

Hello

I would like to have an exact 1:1 mirror of two repositories using Skopeo. However, from the skopeo sync description:

Synchronize images between registry repositories and local directories. Synchronization is achieved by copying all the images found at source to destination - useful when synchronizing a local container registry mirror or for populating registries running inside of air-gapped environments.

What's the difference with skopeo copy then?

In my opinion, this command should work like rclone's sync. From their docs:

Sync the source to the destination, changing the destination only. Doesn't transfer files that are identical on source and destination, testing by size and modification time or MD5SUM. Destination is updated to match source, including deleting files if necessary (except duplicate objects, see below). If you don't want to delete files from destination, use the copy command instead.

Is there any way I can do what I want? This is the command that I believe gets closer to what I want to achieve:

skopeo sync -a --preserve-digests -s docker://ghcr.io/my/image -d docker://docker.io/my/image

[mtrmac]

Thanks for reaching out.

I think that would be an interesting behavior, but after years of existence of skopeo sync, we simply can’t change what the command does and break existing scripts.

Adding an option would be possible — except that the underlying code doesn’t support deleting tags ( #1432 ), so that would need to be implemented first.

[ferferga]

@mtrmac Why so? I think this can be done in a major. Current skopeo sync users just need to switch to skopeo copy for what they want to do (I don't really understand what's the difference between both commands?). So we match 1:1 rsync/rclone commands.

[mtrmac]

We haven’t had a new major release in years; and merely deciding to make a major release does not change the calculation that this breaks scripts and costs all existing users; “this is a major release” a description of a decision, not a reason to make that decision.

We are not very likely to run out of subcommand or option names, so breaking the existing command names seems unwarranted to me.

---

don't really understand what's the difference between both commands

One difference is in all the automation to list+filter tags. Plus different performance trade-offs.