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-contai...
# 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.
[2]
https://gitlab.com/fedora/sigs/go/package-data