replace hashicorp/go-multierror with errors.Join

[thaJeztah]

• depends on Add Go 1.22 and 1.23, rm old versions, bump CI actions, bump golangci-linter #776

[thaJeztah]

Ah, right, this requires go1.20 as minimum, which perhaps by now may be fine?

[kolyshkin]

@thaJeztah #776 is merged; time to rebase

[thaJeztah]

I need to check if I'm actually doing these right; I recently made a mistake with stdlib "multi-errors" because (IIRC) errors.Join is more an equivalent to errors.Wrap, and nests a new error, not making it on the same "level" as other errors when using a loop.

[kolyshkin]

With #777 we're switching to go 1.21 as a minimum so once merged we can merge this one as well.

[thaJeztah]

Rebased after #777 was merged

[thaJeztah]

@kolyshkin @tianon PTAL

[kolyshkin]

Wonder if we can actually test it (or is it tested already). If yes, I'm all for it.

[kolyshkin]

lgtm

[tianon]

I think https://github.com/opencontainers/runtime-tools/graphs/contributors tells a pretty clear story about whether or not anyone is actively maintaining the code in this repository in 2025 (and frankly even as far back as 2019), and I'd honestly suggest that any project finding value from it should probably be thinking about either forking or adapting to some new library, if there's some code here that's still useful.

Is there a particular reason you're looking at this, Seb? Some transitive dependency pulling this into a project you maintain?

oci-runtime-tool is a collection of tools for working with the OCI runtime specification.

Like honestly, this description is really runc, right? I get that this repository does something slightly different, but to what end? We had some lofty goals, but I don't think they were ever really realized.

[thaJeztah]

Oh! I actually forgot my own comment to have another look at "wrap" vs "same level"; #778 (comment)

Is there a particular reason you're looking at this, Seb? Some transitive dependency pulling this into a project you maintain?

Yeah, I recalled this PR when I updated this in containerd (containerd/containerd#12320) to get rid of some transitive dependencies (including the unmaintained github.com/syndtr/gocapability), when I realised the go-multi-error was still there because this PR was still pending;

and I'd honestly suggest that any project finding value from it should probably be thinking about either forking or adapting to some new library, if there's some code here that's still useful.

Yeah, I fully agree; this project is not really maintained, so any user of it may expect specs generated by it to be outdated and/or missing changes from current OCI specs.

I think for most it's just as a convenience to either generate an OCI spec in (integration) tests, but for others it looks to be used a part of their core functionality; at least these come to mind;

• CDI (tags.cncf.io/container-device-interface)
• NRI (github.com/containerd/nri)
• containerd (related to the NRI implementation inside containerd itself)
• Nydus snapshotter (github.com/containerd/nydus-snapshotter)
• github.com/containerd/accelerated-container-image

For containerd ... it's actually slightly surprising, because it's depending on runtime-tools to implement many things that containerd itself also implements (through its own oci.WithXXX functional options). I guess for the nri module, possibly "all of containerd" as dependency may be rather heavyweight, but yeah, possibly an option (either that or a fork / own implementation or things they need).

[cyphar]

FWIW, we do use oci-runtime-tool for generating config.json and for validating the bundles we create with umoci unpack. However, the lack of maintenance here means that umoci has been functionally stuck on runtime-spec v1.0.2 for >5 years now.

I finally managed to remove the oci-image-tool dependency last month, so I may just decide to remove oci-runtime-tool as well. The validation stuff would be quite nice to keep but I really don't know whether it makes sense to keep somewhat-alive projects tied to basically-dead projects like this...

Like honestly, this description is really runc, right? I get that this repository does something slightly different, but to what end? We had some lofty goals, but I don't think they were ever really realized.

For oci-image-tool validate there is theoretically a migration path (implement the validation in umoci -- not sure when I'll get around to that) but that doesn't really exist for oci-runtime-tool validate (runc has its own very peculiar validation logic in specconv and we probably aren't ever going to migrate to using the runtime-spec internally).

The validation stuff in this repo was meant to end up tying into compliance but that never really got off the ground AFAIK.