remove slirp4netns from the default package set

[miabbott]

As part of the investigation of moving to support bootable containers, there was some discussion about the inclusion of slirp4netns as part of a base image - https://gitlab.com/fedora/bootc/base-images/-/merge_requests/51

There was debate about why that package was included, which goes back to the early days of supporting rootless containers in the podman stack.

We can see evidence of that rationale when it was originally included in IoT - https://pagure.io/fedora-iot/ostree/c/41b6b08aa577ecb827996296712210ce1889040c?branch=master

Since podman v5, the default rootless networking tool has been pasta - https://blog.podman.io/2024/03/podman-5-0-breaking-changes-in-detail/

This rolled out as part of Fedora 40 (I think?) and has had significant time to soak in Fedora and Fedora IoT.

Nothing in IoT depends on slirp4netns anymore, with the introduction of the pasta tool:

[core@localhost ~]$ rpm -q --whatrequires slirp4netns
no package requires slirp4netns
[core@localhost ~]$ rpm -q --whatrecommends slirp4netns
no package recommends slirp4netns

In an effort to keep IoT both slim and modern, I'd advocate that we should remove the package from the default set.

[nullr0ute]

The reason it wasn't removed was because of migration for existing users isn't automatic so for an upgrade they would end up without networking which is probably not a great user experience.

[miabbott]

OK, I understand that perspective.

How long should we carry the package in IoT?

I don't expect to see any migration tools emerge from the containers stack, but I also don't think carrying the package indefinitely is the right move either.

[nullr0ute]

OK, I understand that perspective.

How long should we carry the package in IoT?

Well the podman 5 feature which changed the default was only part of F-40, AKA the current stable release. What should we consider a reasonable time? Also how should we educate IoT users of this sort of "your stuff will break if you don't update" sort of change?

I also don't think carrying the package indefinitely is the right move either.

Never said it should be carried indefinitely, is 1 full cycle, 2 cycles considered reasonable? Do other variants such as CoreOS have a policy here?

[miabbott]

What should we consider a reasonable time?

That's what I was trying to get from you! 😛

Just trying to solicit opinions on this kind of topic.

Do other variants such as CoreOS have a policy here?

The policy CoreOS uses is somewhat vague as documented. In practice, they often work to have migration code/workarounds in place, then deprecate/remove items along the usual next/testing/stable cadence (optimistically 6 weeks from next to stable). (See: coreos/fedora-coreos-tracker#1130, coreos/fedora-coreos-tracker#676)

(In the case of slirp4netns, they still carry it as of this writing, with no deprecation plans as far as I can tell: https://github.com/coreos/fedora-coreos-config/blob/cabe5eed396d10db449628b63935122b4464eea7/manifests/fedora-coreos-base.yaml#L108. They also expliclitly include passt - https://github.com/coreos/fedora-coreos-config/blob/cabe5eed396d10db449628b63935122b4464eea7/manifests/user-experience.yaml#L46-L47)

Six weeks doesn't seem feasible for IoT, so I would strawman announcing the deprecation in release X and actually doing the removal in X+2. That allows us to make the change in fedorar/rawhide/x86_64/iot, get promoted to fedora/devel/x86_64/iot and then rolled out as fedora/stable/x86_64/iot. (You could convince me to do it in X+1 pretty easily)