-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Containerd package shouldn't provide runc which is packaged by distros already #101
Comments
Agree. I have a started working on it in main...crazy-max:docker-packaging:runc-package while making a package for BuildKit because today it also depends on runc. |
From what I see, you split runc in a separate package, but still you package it yourself. Shouldn't this task be left to the distros instead (who package it already) ? |
Well I think it's better to have a separate package and make it available on download.docker.com. OS one is often outdated. |
Mmmh honestly I think this is some work you will try to maintain on your side which in quite some cases won't even be used. By experience, what you want to do works with .deb, but not with .rpm. For RHEL (the distro I care about), runc uses epoch 4 (see https://gitlab.com/redhat/centos-stream/rpms/runc/-/blob/e1b1ec00e2a4f8f7cb1589ea65207ba0fa8e8864/runc.spec#L20) so no matter how recent is the version you will package, the official RHEL package will always "win" against yours, as it will have a bigger epoch (you specify no epoch in your runc.spec file). This rpm's epoch is distro specific (ie there is no reason it's the same between fedora/RHEL 8/RHEL 9) and it changes when the distro wants (actually I already opened couple of requests to Red Hat which resulted in a change of epoch in some of the container related packages, like podman or catatonit). |
Yes indeed, the branch on docker/packaging is still a draft and needs more work to take into account epoch and also changes for other packages to make them depend on it. |
Hi,
As a continuation of the issue in the current repository docker/containerd-packaging#210 I think we should simply stop trying to compile/package runc here. We are in 2023, distros now all have a runc package I guess, which hopefully is well maintained. Installing containerd with runc already installed shouldn't result in the system runc package to be uninstalled (making typically a co-installation with podman fail).
Cheers,
Romain
The text was updated successfully, but these errors were encountered: