Add upgrade --dry-run or so

[cgwalters]

So that client-side automation tooling can poll for updates before downloading. xref coreos/rpm-ostree#4176 etc.

[jbtrystram]

I started to work on this as a first contribution but I am unsure how to wire things up.
Determining if a new update is available without pulling the whole image requires to run skopeo inspect and look at the digest of the remote image.
This quite easy to implement but I see that skopeo and podman utils are gated behind the install feature, and given #81 , I suppose adding a requirement on skopeo for the upgrade subcommand is not something we want.

Given this comment https://github.com/coreos/rpm-ostree/pull/4486/files#r1246174405 it appears there is the necessary bits in ostree-rs-ext ?
I'll keep looking around but I wanted to make sure I am on the correct path, as I am just discovering all this ecosystem :)

[cgwalters]

This quite easy to implement but I see that skopeo and podman utils are gated behind the install feature, and given #81 , I suppose adding a requirement on skopeo for the upgrade subcommand is not something we want.

No; bootc hard requires https://github.com/ostreedev/ostree-rs-ext/ which hard requires skopeo (indirectly via https://github.com/containers/containers-image-proxy-rs )

That's how upgrades work (which is related to but distinct from installs).

Given this comment https://github.com/coreos/rpm-ostree/pull/4486/files#r1246174405 it appears there is the necessary bits in ostree-rs-ext ?

Yes, just see the code implementing bootc upgrade - the key bit is https://docs.rs/ostree-ext/0.11.1/ostree_ext/container/store/struct.ImageImporter.html#method.prepare which is exactly the "fetch manifest without fetching layers".

[cgwalters]

Also, welcome and thanks for your interest!

[jbtrystram]

@cgwalters awesome ! Thanks for the clarification !