vendor: github.com/klauspost/compress v1.18.2

[thaJeztah]

No changes in vendored code

Fixes a regression in v1.18.1 that resulted in invalid flate/zip/gzip encoding. The v1.18.1 tag has been retracted.

full diff: klauspost/compress@v1.18.1...v1.18.2

[tonistiigi]

This looks like an indirect dependency that should be updated via buildkit vendor.

[thaJeztah]

It would eventually be updated through BuildKit as well (once moby/buildkit#6390 lands in a release), but go modules are designed around MVS (Minimal Version Selection), so users (like buildx) can update to compatible higher version;

Minimal version selection assumes that each module declares its own dependency requirements: a list of minimum versions of other modules. Modules are assumed to follow the import compatibility rule—packages in any newer version should work as well as older ones—so a dependency requirement gives only a minimum version, never a maximum version or a list of incompatible later versions.

In this case, the module version specified here no longer exists; it was retracted. I guess technically it would be considered a bug in go mod to disregard that, and in case of a retracted module, it should either downgrade to the previous version (if no higher version exists), or update to the higher version.

[tonistiigi]

Yeah, I didn't mean that it would make the version calculation incorrect, but just that it is a mess to manage dependencies when projects that don't actually use it change to a different version from the upstream. Similar to why I'd like the core dependencies that are shared with containerd to come with containerd vendor (although these are mostly direct dependencies).

I'm adding this to the next milestone so if for some reason we don't get it via buildkit vendor before next release cycle we can take this directly.

[thaJeztah]

Ultimately, //indirect is just a comment, for many dependencies there's not a canonical "owner", so it's the "final" project you're working that's responsible for keeping dependencies up-to-date (with compatible versions), not (indirect) dependencies to push the versions up (otherwise we'd have to keep doing new releases of, e.g., moby/sys/xxx to drive versions up https://github.com/moby/sys/blob/9dc3a90b82699c54554635f76a6a49757e02c523/mount/go.mod#L7

That's also how distro packages are built; there's always a single version of every go module in use ... for all Go projects. If (say) golang.org/x/sys is updated, it's updated for all Go packages shipping in the distro.

In either case, I opened this PR, because I didn't want to update BuildKit to master and keep it on a tagged version, but both BuildKit and CLI would be updating the version (but the CLI is not a go module yet, so I wanted to do it ahead of time (for #3569). Now that that PR is open, we could merge that one instead, which includes this commit.