+1

Thanks for the thoughtfully written change proposal. My only worry is that there are some fairly popular packages in that list, such as emacs and gnucash. If you can do your best to coordinate with those maintainers, that would be great.

Emacs is already fixed in F39 (that list is from F38).

Gnucash is fixed upstream and we just need to update the downstream BuildRequires. I can look into that.

For the others, it's too many packages for me to look at them all individually, but I can make an effort to mail the maintainers at least.

Repeating the query from the original devel email, but for Rawhide:

$ mock -r fedora-rawhide-x86_64 --dnf-cmd -- repoquery --whatdepends webkit2gtk4.0 --latest-limit 1 --arch 'noarch,x86_64'
apostrophe-1:2.6.3-6.fc38.noarch
apvlv-0:0.4.0-2.fc38.x86_64
atril-libs-0:1.26.1-1.fc39.x86_64
badwolf-0:1.2.2-4.fc38.x86_64
balsa-0:2.6.4-2.fc38.x86_64
bookworm-0:1.1.3-0.9.20200414git.c7c3643.fc38.x86_64
cairo-dock-plug-ins-webkit-0:3.4.1-42.20210730gitf24f769.fc38.1.x86_64
claws-mail-plugins-fancy-0:4.1.1-5.fc38.x86_64
eclipse-swt-1:4.27-1.fc39.x86_64
emacs-1:28.2-4.fc38.x86_64
ephemeral-0:7.1.0-5.fc38.x86_64
exaile-0:4.1.2-2.fc38.noarch
exfalso-0:4.5.0-5.fc38.noarch
fapolicy-analyzer-0:1.0.1-1.fc39.x86_64
foliate-0:2.6.4-6.fc38.noarch
gambas3-gb-gtk3-webview-0:3.18.2-1.fc39.x86_64
gamehub-0:0.16.3.2-6.fc38.x86_64
geany-plugins-markdown-0:1.38-9.fc39.x86_64
gnucash-0:5.0-1.fc39.x86_64
gphotoframe-0:2.0.2-17.hg2084299dffb6.fc38.1.noarch
gthumb-1:3.12.2-7.fc39.x86_64
liferea-1:1.14.5-1.fc39.x86_64
lutris-0:0.5.12-4.fc39.x86_64
marker-0:0.0.2020.04.04-10.fc38.x86_64
meteo-0:0.9.9.1-4.fc38.x86_64
midori-0:9.0-12.fc38.x86_64
minigalaxy-0:1.2.2-3.fc38.noarch
notes-up-0:2.0.6-4.fc38.x86_64
osmo-0:0.4.4-2.fc38.x86_64
pdfpc-0:4.6.0-1.fc38.x86_64
perl-Gtk3-WebKit-0:0.06-27.fc38.noarch
rubygem-webkit2-gtk-0:4.1.2-1.fc39.noarch
sugar-0:0.120-2.fc38.noarch
sugar-browse-0:207-6.fc38.noarch
sugar-toolkit-gtk3-0:0.120-3.fc39.x86_64
surf-0:2.0-15.fc38.x86_64
ulauncher-0:5.15.2-1.fc39.noarch
vfrnav-0:20201231-38.fc39.x86_64
vimb-0:3.6.0-2.fc39.x86_64
webkit2-sharp-0:0-0.17.20170219gita59fd76.fc38.x86_64
webkit2gtk4.0-devel-0:2.41.3-1.fc39.x86_64
webkit2gtk4.0-doc-0:2.41.3-1.fc39.noarch
wxGTK-webview-0:3.2.2.1-1.fc39.x86_64
xiphos-0:4.2.1-18.fc38.x86_64
xreader-libs-0:3.6.3-1.fc38.x86_64
yad-0:9.3-5.fc38.x86_64

I used the following command to find packages that still depend on libsoup2:

$ mock -r fedora-rawhide-x86_64 --dnf-cmd -- repoquery --whatdepends 'libsoup-2.*' --latest-limit 1

The intersection of the two sets of packages (less the webkit2gtk4-* packages themselves) is:

• apvlv
• badwolf
• balsa
• bookworm
• claws-mail-plugins-fancy
• emacs (this is on the list only because the fix was not built yet)
• ephemeral
• exaile
• exfalso
• gambas3-gb-gtk3-webview
• gamehub
• geany-plugins-markdown
• gthumb
• liferea
• meteo
• midori
• pdfpc
• surf
• vfrnav
• vimb

That is still quite a lot of packages, some of them reasonably popular, that would need to be hastily ported to libsoup3 in order to stay in the distribution. I wonder how many of these would be able to manage it.

I probably should have also cross-checked against something like

$ mock -r fedora-rawhide-x86_64 --dnf-cmd -- repoquery --whatrequires 'libsoup-2.*' --recursive --latest-limit 1

to get a better sense of the impact, but I didn’t go that far.

+1, meh

+1 time marches on

I assume an interested party could create a compat package for the old webkitgtk version that supports libsoup 2?

I assume an interested party could create a compat package for the old webkitgtk version that supports libsoup 2?

Yes, and the Fedora 36 package would be a good starting point for this. That said, compat packages are likely to encourage packages to not update to the newer WebKitGTK, so I'd hesitate to recommend this.

The contingency mechanism is:

Bring back the removed subpackages

I assume that just means reverting the change in webkitgtk.spec.
But there's also the option of creating a compat package. I think that'd be nicer, as it would shift the burden of maintenance onto a different group of volunteers, and also make it more clear that the package is on life support. So if it turns out that something cannot be ported and somebody really wants to keep it alive in F39, I would prefer for a compat package to be created. But we can punt on this decision until the need arises.

+1 too.

[I wrote a longer comment yestarday, but it failed to submit because of a network glitch :( ]

+1

The contingency mechanism says "restore removed subpackages", but the alternative is (already proposed) to create a compat package. I think updating everything is the best outcome, but if we don't manage to do that in time for F39 and people want to preserve things, a compat package is better than bringing back the subpackages, because it removes the burden for the maintainers of webkitgtk. But I hope we make an effort to rebase as much as possible, and only stick with the compat version as a last resort.

+1

I've just changed the target release from F39 to F40. That means removal would not occur in rawhide until August, right after F39 is branched, giving a little additional time for package maintainers to port. And stable users won't be affected until F40 in April. I'll mail affected package maintainers to give heads-up after this ticket is approved.

Given the change in targeted release, I'm going to wait an additional day to process this vote in case any FESCo members want to raise a concern (I can't imagine why, but it seems like the wise thing to do)

+1 here

With no objections to the re-target, the vote is

APPROVED (+5,0,-0)

Announced in the agenda for today.

I've just mailed all maintainers of affected packages as a heads-up.