Un-provide runc

[h-vetinari]

This issue proposes a different approach than #38185 to the same underlying issue:

Long term (or hopefully not so long, depending how long the OCI hooks issue takes), the goal should IMO be to stop vendoring runc completely, and depend on it as a separate package - I believe this view is shared by @thaJeztah as well

I understand that before that happens, moby/containerd wants to tightly control which runc gets used to avoid regressions, which is fair enough. My point is that to achieve that control, runc should be vendored, but not provided (from the POV of deb/rpm spec). This will likely mean having to adapt the location/PATH where the installation puts it to somewhere private to moby/containerd, but should otherwise not have big repercussions...?

There are other projects that have their own requirements for runc (e.g. podman; in fact, @rhatdan asked me to open this issue in containers/podman#2887), and currently, it's not possible to install docker alongside them, or build one's own runc without having to play with PATH-variables.

Xref: the already merged conflict updates

[thaJeztah]

Until runc reaches 1.0 it likely won't be packaged separately, given that there's still breaking / incompatible changes between their releases.

Once runc reaches stable (1.x), and there's a stability guarantee, this will open the possibility to package it separately, and to make it a dependency for containerd

[h-vetinari]

@thaJeztah
Well, runc already is packaged separately (for example on ubuntu).

But beyond the question of reaching version 1.0, it would be possible for moby/containerd to vendor runc without providing it, no? That moby/containerd wants to use their own runc is fair enough, but providing it affects what else can be installed on the same system.

[thaJeztah]

docker / containerd won't be able to run without runc, and using other versions of runc has lead to various hard to find problems in the past, so I don't think this will be a feasible solution right now

[h-vetinari]

@thaJeztah: docker / containerd won't be able to run without runc, and using other versions of runc has lead to various hard to find problems in the past [...]

I understand that, and I'm proposing neither one of those things. I'm saying docker/containerd could vendor runc (for example) in a private directory, without affecting the rest of the system by declaring provides runc.

[AkihiroSuda]

So like /usr/libexec/docker/runc?

[h-vetinari]

@AkihiroSuda Like that, yes. :)

[h-vetinari]

BTW, after runc 1.0.0 GA this should be back on the table? Kubernetes is looking to take things even one step further by completely unvendoring runc.

[thaJeztah]

Kubernetes is looking to take things even one step further by completely unvendoring runc.

FWIW, that's a separate issue; the vendor code (runc libcontainer) is separate from the binaries that are provided.