On Wed Mar 27, 2024 at 16:53 +0100, Mikel Olasagasti wrote:
Hi Maxwell,
Hi Mikel!
One doubt about other packages that currently depend on any of the packages you list to be vendored.
Yes, that's a good point. Thank you for raising it!
Checking your containerd spec[1] I see the only the binary package is installed, no -devel package is created.
If that's correct I undrestand that all the packages that depend on it will fail?
I plan to create a transitional golang-github-containerd package[1] that will only provide the -devel subpackage. This Provides `deprecated()` (meaning that nothing new is allowed to depend on it), and I plan to eventually remove it once other packages are handled.
[1] https://git.sr.ht/~gotmax23/docker-ng/tree/main/item/golang-github-container...
# fedrq whatrequires-src -X -F source containerd
You probably want to use `fedrq whatrequires containerd-devel` instead. Some of these depend on the main containerd application and not the -devel subpackage,
golang-github-containerd-aufs golang-github-containerd-fuse-overlayfs-snapshotter golang-github-containerd-imgcrypt golang-github-containerd-nri golang-github-containerd-stargz-snapshotter golang-github-containerd-zfs
The main users of these libraries are containerd itself.
golang-github-docker golang-github-docker-cli
These will be kept around for now (they'll depend on the transitional -devel package I mentioned).
golang-github-moby-buildkit
This will kept around until we can get rid of golang-github-docker* and golang-github-containerd-* packages.
golang-github-tonistiigi-fsutil
Only golang-github-docker and containerd-devel depend on this.
golang-gvisor
This package has been FTBFS since Fedora 37 and is up for retirement— well, the retirement has been pushed off for a release cycle to avoid breaking a bunch of things, but that cannot happen forever.
golang-helm-3
This package will probably end up getting vendored for the same reasons as containerd and docker.
golang-oras-1
Only helm uses this.
kubernetes
kubernetes only depends on containerd.
moby-engine
Ditto.
If so, golang-github-docker would break other packages/binaries like `doctl`.
<snip>
And the chain of broken deps could be quite large.
Have you checked the impact this could have?
The plan is to add the transitional golang-github-containerd package and keep the current versions of the golang-github-docker-* libraries until we can go through the dependency tree. Yes, this will have some impact on the other packages in the ecosystem. That is the idea behind the two-step plan: I do not want containerd and moby-engine to rely on the broken, out-of-date container library ecosystem anymore; but I also want to take a careful approach to the packages outside the Docker ecosystem that removing the library package will affect. The fedrq and Go Package Data tooling [2] that we already have in place will assist this effort.