$ dnf repoquery --whatrequires libsoup --latest-limit 1 --arch 'noarch,x86_64' --disablerepo='*' --enablerepo=rawhide --recursive | wc -l
1407

I am not sure if "We will remove libsoup 2 and all packages that still depend on it" is plausible. This would have a huge impact.

Yes, there will be some package carnage. But if we don't do it for F39 next year, then when? Do it for F40 in 2024? I don't think 2024 will look meaningfully different from 2023.

It looks a lot better if you don't use --recursive. There's really just a few critical packages that need fixed, like geoclue2, which truly block the entire distro. If these packages are not ported in time, we stop depending on them and move on.

Yes, there will be some package carnage.

I don't think this is acceptable. And yes, I might be biased, because I already needed to remove the Pantheon desktop from Fedora 37+ because of this libsoup3pocalypse (upstream just doesn't have the manpower to port everything in time for the F37 release, and I can't help either).

It looks a lot better if you don't use --recursive.

Not really. There's still a few critical / popular / GNOME applications in this list:

• cinnamon
• darktable
• emacs
• flatpak-builder
• geoclue2 / geoclue-glib
• gnome-{calculator,games,music,software}
• libgweather
• liferea
• polari
• rhythmbox
• snapd-glib
• etc.

I don't think we should retire emacs and half the GTK app ecosystem in Fedora 39 if they're not ported to libsoup3 in time.

The GNOME core dependencies and apps (flatpak-builder, geoclue2, geoclue-glib, gnome-calculator, gnome-music, gnome-software) will be ported upstream because GNOME will follow approximately the same deadline as Fedora for libsoup 2 removal. (Note libgweather is already ported; that's an older compat package.)

As for all the other stuff: I guarantee most of it will not be ported without a motivating deadline. If FESCo isn't willing to establish a hard deadline and wants to wait for packages to voluntarily port first, libsoup 2 will stick around indefinitely, long after it is abandoned upstream. In this case, we'll orphan libsoup 2 instead of retiring it, and somebody else will likely pick it up and keep it alive in Fedora, same way GLib 1 and GTK 1 are still kept around 20 years later. The notable difference is GLib 1 and GTK 1 are not network-facing and don't have a history of problems.

The problem with a "motivating deadline": Who are they supposed to motivate? Most package maintainers are already overcommitted and don't have time to deal with a sword hanging over their head. Are they supposed to make upstream projects care about a problem that they will most likely perceive as "self-inflicted by/on Fedora"?

Not to mention, it's actually upstream's responsibility to provide a porting guide and notify notable stakeholders. I haven't seen any such communication from GNOME on this front, which in my view makes this kind of a botched process.

The porting guide is here and the upstream announcement is here. (Note that we are turning off upstream mailing lists, so Discourse has replaced use of mailing lists for announcements. I did forget to give that thread the "announcement" tag, though, which I've just fixed.)

The problem with a "motivating deadline": Who are they supposed to motivate? Most package maintainers are already overcommitted and don't have time to deal with a sword hanging over their head. Are they supposed to make upstream projects care about a problem that they will most likely perceive as "self-inflicted by/on Fedora"?

It's either that, or continue to depend on libsoup 2 indefinitely. That's really the choice FESCo has to make here. Reminder that there is still five months until my proposed retirement date, and 14 months before we would release a stable Fedora without libsoup 2, so there's still a pretty reasonable amount of time to port things.

You make it sound like it's an either-or situation. Either we retire it in Fedora Linux 39 or it will be orphaned-taken and stays forever. That are however not the only 2 options. See for example https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Transition_Steps -- you could do something similar:

1. deprecate the package in Fedora 38 (IMHO should have been done via https://fedoraproject.org/wiki/Changes/libsoup_3:_Part_One if you planned the removal but too late for that)
2. issue a general ban unless a reason is given (with Python 2 we agreed that we open bugzillas and packages that will keep them NEW will be orphaned)
3. a later release, collect the remaining stats and make a new informed decision
4. if needed, make FESCo exceptions necessary for old libsoup dependency after (3)

Also, it seems that libsoup 2 is part of RHEL 8 and RHEL 9. As long as it is maintained there I suppose security fixes should exist even when upstream abandons this, no?

You make it sound like it's an either-or situation. Either we retire it in Fedora Linux 39 or it will be orphaned-taken and stays forever.

It's true. :) My real goal is to ensure the package gets removed before Fedora 40. I chose to target Fedora 39 just in case we're unable to remove it in time. (Red Hat will not continue to maintain this package for longer than that.)

That are however not the only 2 options. See for example https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Transition_Steps -- you could do something similar:

1. deprecate the package in Fedora 38 (IMHO should have been done via https://fedoraproject.org/wiki/Changes/libsoup_3:_Part_One if you planned the removal but too late for that)

I didn't know this was a thing. We could do that as part of the current change proposal.

Also, it seems that libsoup 2 is part of RHEL 8 and RHEL 9. As long as it is maintained there I suppose security fixes should exist even when upstream abandons this, no?

In theory, but in practice that is unlikely to happen when upstream has moved on, which is why we're trying to phase it out as soon as possible. Red Hat's commitment to provide security updates ends once we deprecate the package. Also, we only commit to fixing issues that are rated Important or Critical priority, which excludes a lot of CVEs that Fedora users would find objectionable.

After a week, I see only discussion, no votes. Tagging for meeting.

@catanzaro

FESCo requests the creation of an "affected package list" and "must-port" requirements. We will revisit then. (sgallagh, 18:02:14)

The affected package list is already part of the change proposal (see the bottom). I could change it to be recursive, at the cost of including packages where no action is required.

I can make short a list of must-port packages, sure.

I've added a list of must-port packages to the bottom of the change proposal. Most of these don't actually directly depend on libsoup 2: maintainers need to investigate their dependency trees to see what is pulling in libsoup 2

What is the difference between "Packages in Fedora 37 Workstation Beta that recursively depend on libsoup 2 " and "Essential packages we cannot live without". If e.g. rhythmbox isn't solved, we remove it from workstation instead?

What is the difference between "Packages in Fedora 37 Workstation Beta that recursively depend on libsoup 2 " and "Essential packages we cannot live without". If e.g. rhythmbox isn't solved, we remove it from workstation instead?

Yup. It's a very arbitrary list of what seemed most important to me. I omitted most of the GNOME apps there, which are blockers for upstream but not downstream. Rhythmbox doesn't need to be a blocker regardless because we've been trying to replace it with Music for years, and don't plan to keep it in F38 default install.

I think that retirement is a no-go. The package should be marked as deprecated. I'd do this even in for F37. Obviously, you can also orphan the package. Most likely it'll stay around in Fedora until enough of the dependencies have been ported or retired. This is annoying, but unfortunately it's how those transitions go.

To add to the list that @churchyard posted above:

1. open bugzillas (automatically) against all packages depending on libsoup2

This will be discussed during FESCo meeting today at 17:00 UTC. @catanzaro (and anyone else interested) are invited!

This was discussed during today's meeting:
AGREED: The change in current form is rejected. We encourage the Change Owner to resubmit with deprecation and a plan to orphan instead (+5,0,0)