drop golang.org/x/exp plan

[pacoxu]

When I bump runc to v1.2.0, we are happy to see that github.com/cilium/ebpf can be dropped.
And we find the golang.org/x/exp is still in use.

https://github.com/kubernetes/kubernetes/blob/fdc48b929d2c8132d2163e35c0224e18006b01e2/hack/unwanted-dependencies.json#L66

      "golang.org/x/exp": "This subrepository holds experimental and deprecated packages",

The repo holds experimental and deprecated packages and so we want to finally drop it.

More kubernetes/kubernetes#128261 (comment).

BTW, this may be effected by kubernetes/kubernetes#128157 which is in progress.

[cyphar]

We don't use golang.org/x/exp, it's only used by github.com/cilium/ebpf:

% git grep "golang.org/x/exp"
go.mod: golang.org/x/exp v0.0.0-20230224173230-c95f2b4c22f2 // indirect
go.sum:golang.org/x/exp v0.0.0-20230224173230-c95f2b4c22f2 h1:Jvc7gsqn21cJHCmAWx0LiimpP18LZmUxkT5Mp7EZ1mI=
go.sum:golang.org/x/exp v0.0.0-20230224173230-c95f2b4c22f2/go.mod h1:CxIveKay+FTh1D0yPZemJVgC/95VzuuOLq5Qi4xnoYc=
vendor/github.com/cilium/ebpf/internal/math.go:import "golang.org/x/exp/constraints"
vendor/modules.txt:# golang.org/x/exp v0.0.0-20230224173230-c95f2b4c22f2
vendor/modules.txt:golang.org/x/exp/constraints

I don't know why go mod tidy is pulling it in in Kubernetes, but it's not coming from runc itself.

[pacoxu]

we use go mod graph to show the dependencies.

It seems that this will include an indirect dep in the result.

(base) ➜  runc git:(main) go mod graph                     
github.com/opencontainers/runc golang.org/x/exp@v0.0.0-20230224173230-c95f2b4c22f2
github.com/cilium/ebpf@v0.16.0 golang.org/x/exp@v0.0.0-20230224173230-c95f2b4c22f2

runc/go.mod

Line 38 in 0b9fa21

golang.org/x/exp v0.0.0-20230224173230-c95f2b4c22f2 // indirect

[cyphar]

It's included because we use that package within runc, but you aren't importing code that uses that package in Kubernetes. It seems to me that there's a limitation (either in go mod graph or go mod in general) that results in Go thinking that the we hard-require it as opposed to it being a transitive dependency from code that you aren't importing.

I'm not sure what we can really do about it from our side. To be honest, I'm a little surprised go mod doesn't seem to handle this case.

[dims]

@cyphar as long as runc is not directly using it we are golden. we (k8s) will chase the other issues.

[kolyshkin]

As I mentioned in kubernetes/kubernetes#128276 description (see "2."), it seems to be a bug in kubernetes' hack/lint-dependencies.sh implementation.

[liggitt]

it's not a bug, runc is actually expressing and passing along the exp dependency (xref kubernetes/kubernetes#128261 (comment)), but as long as runc isn't directly using it, there's nothing you can do but wait for ebpf to cut a new tag that includes cilium/ebpf#1557 and update to that

[pacoxu]

We're looking at one more major release before the end of the year.

refer cilium/ebpf#1596, we may wait for the cilium/ebpf next release in the end of year.