This doesn't describe at all what purpose the wrapper / this PR serves.

@GrahamcOfBorg test docker-tools

It would be nice to set the path at build time, to avoid this wrapper. I created the issue containers/storage#622 to track this.

We could actually build a storage.conf file with the path of the fuse-overlay binary and make this file the default one at build time.

• the variable we'd need to set: https://github.com/containers/storage/blob/af9373689503bc923c8e1da2ab8ddcdda1e75a62/store.go#L3400)
• and the configuration value to set: https://github.com/containers/storage/blob/master/storage.conf#L74

We could actually build a storage.conf file with the path of the fuse-overlay binary and make this file the default one at build time.

If we change the default path to this file at build time will it still read from /etc/containers/storage.conf as well?

@zowoq No, Skopeo will not read the /etc/containers/storage.conf file anymore (as it is already the case for the default policy file).

No, Skopeo will not read the /etc/containers/storage.conf file anymore

I don't think that it is a good solution then. /etc/containers/storage.conf is used by other programs (and will probably end up being managed by the virtualization.containers module) and I don't think it should be ignored.

(as it is already the case for the default policy file).

The policy file can now be managed by the virtualization.containers module which presents another problem.

But we can still change the policy file path on CLI which doesn't seem to be possible for the storage.conf file. Moreover, if rootless is enabled, our storage.conf file will not be used.
So, forget what I said and let's do it with the wrapper.

docker-tools tests depending on Skopeo works fine.

@nlewo Would you have an objection if I sent a PR to remove setting the policy at build time?

It's not very clear (and somewhat surprising TBH) that the config in /etc/containers/policy.json will be silently ignored unless skopeo --policy /etc/containers/policy.json is used.

skopeo does throw a fairly clear error if the file doesn't exist and has an --insecure-policy option to ignore the error.

@zowoq When there is no /etc/containers/policy.json file, will skopeo still be working without having to manually specifying it?

Without a policy file it will stop working but passing --insecure-policy will allow it to work.

The user who wants to use Skopeo from nixpkgs would then have to understand what this flag means and why it is needed. So, this is a bit annoying...
What about opening an issue on Skopeo to ask if it could work without this file?

What about opening an issue on Skopeo to ask if it could work without this file?

This file is used by other tools so I don't see how upstream could special case this tool to work without it by default.

I've opened #87821, we can continue discussion there.