New release please

[onlyjob]

Back in the days (~2016) when oci-image-tool was provided by image-spec we introduced oci-image-tool 1.0.0~rc2 into Debian.

Now when oci-image-tool has been moved into this repository, the latest tagged version is 1.0.0~rc1 which is lower than older release.

Could you please tag new release, perhaps 1.0.0~rc3 or greater?

Because of this versioning inconsistency I can't upload image-tools to Debian:

Your upload included the binary package oci-image-tool, version 1.0.0~rc1+dfsg-1, for amd64,
however stable already has version 1.0.0~rc2+dfsg-1+b2.

Thanks.

[onlyjob]

#200 will fix this.

[zhouhao3]

#200 will fix this.

I also wanted to release a new version, but the vote on the new version that was launched a long time ago did not pass, and there was no solution for the community, so it was stuck.

[onlyjob]

The problem was introduced when repository was moved -- that's when ~rc2 became ~rc1. Version should have remained the same or became higher, not lower.
Merely tagging RC2 would have resolved the issue and that I believe would not require voting as this very version has been already released.
This is just a tagging inconsistency...

[FranklinYu]

@q384566678 Any news? Shall we simply tag v1.0.0-rc1 as v1.0.0-rc2 as @onlyjob mentioned above? This way https://bugs.debian.org/900900 can go forward. This should be quick and easy without the need of any voting since it's not a final stable release.

[cyphar]

I'll submit a vote for 1.0.0~rc3 on the mailing list, but just for the record I really don't suggest people use this project (except maybe for the image-spec verification).

[FranklinYu]

Hmm… I came here because I thought Podman depends on this (directly or indirectly). @onlyjob Please correct me if that wasn’t the case.

[onlyjob]

Debian bug report says "Blocking: skopeo" and indeed Skopeo uses this library:

https://github.com/containers/skopeo/blob/master/integration/copy_test.go#L23

Also Umoci may have used it. Not sure about Podman...

[cyphar]

@onlyjob umoci does use it for its integration tests (specifically we use it to double-check that our images are valid), and I'm fairly sure that I added the same logic to skopeo's integration tests (after tools kept breaking back in 2017).

Is this an issue for Debian packaging? I've never had an image-tools failure during development (except for where it was a bug in image-tools), so it's a bit odd that Debian would feel the need to re-check something that would've been caught pre-release upstream. Would making the image-tools dependency optional allow you to drop the requirement in Debian? (I'm also fairly sure newer image-tools doesn't like umoci very much, due to some other image-tools regressions.)

[onlyjob]

Not a problem, don't you worry @cyphar. Thanks.

Main concern was that we could not upgrade image-spec without losing some functionality and upload of image-tools is held by this very issue. I'm not aware of any issues in regards to Umoci package. Skopeo probably can be built without image-tools. Making the latter optional in Umoci is probably a good idea but not too important...

it's a bit odd that Debian would feel the need to re-check something that would've been caught pre-release upstream.

Arguably all Golang ecosystem was "pre-release" just a few years ago.
image-spec was introduced as a dependency to several packages and I'm sure most (or all) of them was vendoring "pre-release" libraries, many of which were not versioned at all.

[FranklinYu]

Not sure about Podman...

I got the impression that Podman depends on skopeo from your comment in the issue containers/podman#1742

[onlyjob]

No, Podman does not depend on Skopeo. Somebody just asked about Skopeo and somehow link to corresponding ITP bug was referenced... Podman is already waiting for review in the NEW queue in Debian.

[stevegt]

Please tag a new release, or archive the repo. Leaving an ancient release as the only one tagged is playing havoc with the way Go modules work -- the module machinery tries to use the most recent tagged release instead of the most recent git commit.

If the choice is to not tag a new release, then it would be better to archive this repo as officially frozen -- maybe refer to #223 in the README for instance. I'm starting to think my own group here has likely been spinning its wheels trying to make use of this code instead of starting with umoci in the first place. Archiving and referring would have prevented that. I just now stumbled across #223 -- it's closed, so didn't see it before today.

[cyphar]

I will open a PR for a new release since the tagging problem is really a technical issue, but archiving the project is a little more complicated because the OCI (specifically the OCI Technical Oversight Board) technically doesn't have a mechanism for archiving projects. We have discussed this problem on the OCI TOB calls a few times, but we had other issues to deal with so we didn't get around to creating a mechanism for archiving projects.

However, the idea was that after umoci became an OCI project, the validation logic (which is the only oci-image-tool feature which umoci doesn't have an implementation of) would be moved to umoci and this project would no longer be required. I haven't gotten around to doing that migration yet unfortunately. I'll try to do it sometime next month (it should be relatively straight-forward, but there are some issues with the validation system that I would like to fix as well -- such as the internet dependency -- because they cause issues in umoci's CI).