Update to the latest c/{common,image} which inclused an update to
docker v28, that update is NOT backwards compatible so I had to fix a
few types.
NOTE: handler.ExecCreateConfig is used directly by the bindings. Thus
this is an API break for pkg/bindings. Including docker types as part of
any stable pkg/bindings API was a very bad idea.
I see no way to avoid that unless we never want to docker v28, which is
not easy as the update comes in from c/image and maybe other packages.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
As the title says. This is the last step in the vendor dance for
Podman v5.0.
[NO NEW TESTS NEEDED]
Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
Migrate the Podman code base over to `common/libimage` which replaces
`libpod/image` and a lot of glue code entirely.
Note that I tried to leave bread crumbs for changed tests.
Miscellaneous changes:
* Some errors yield different messages which required to alter some
tests.
* I fixed some pre-existing issues in the code. Others were marked as
`//TODO`s to prevent the PR from exploding.
* The `NamesHistory` of an image is returned as is from the storage.
Previously, we did some filtering which I think is undesirable.
Instead we should return the data as stored in the storage.
* Touched handlers use the ABI interfaces where possible.
* Local image resolution: previously Podman would match "foo" on
"myfoo". This behaviour has been changed and Podman will now
only match on repository boundaries such that "foo" would match
"my/foo" but not "myfoo". I consider the old behaviour to be a
bug, at the very least an exotic corner case.
* Futhermore, "foo:none" does *not* resolve to a local image "foo"
without tag anymore. It's a hill I am (almost) willing to die on.
* `image prune` prints the IDs of pruned images. Previously, in some
cases, the names were printed instead. The API clearly states ID,
so we should stick to it.
* Compat endpoint image removal with _force_ deletes the entire not
only the specified tag.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
