As discussed in https://bugzilla.redhat.com/show_bug.cgi?id=2151495 , a recent build of webkit2gtk4.1 adds a new hard dependency on gstreamer1-plugins-bad-free . This pulls in another 16 packages that weigh about 18M compressed to anything that just wants to use webkitgtk to render HTML, like the installer (which uses yelp to display help pages).
This is just how it's going to be, unless the GStreamer maintainers are willing to start splitting GStreamer plugins into more subpackages.
Can we get any more useful detail than that? What is the thing webkitgtk needs to link to now that it didn't need before, and why did that change? What would splitting it in gstreamer look like? Is there any possibility we could have a build of webkitgtk without any of the AV support, for cases where all we need is a library that can render HTML/XML without multimedia?
(In reply to Adam Williamson from comment #2) > Can we get any more useful detail than that? What is the thing webkitgtk > needs to link to now that it didn't need before, gsttranscoder from gstreamer1-plugins-bad-free > and why did that change? https://github.com/WebKit/WebKit/commit/56ec50c054f07cc92f7c331dc2402b36bb10bb0f > What would splitting it in gstreamer look like? Well GStreamer upstream is already organized into different plugins. We have subpackaged each set of plugins into common plugins to be installed by default, plus extra plugins that most users do not need. For example, we have gstreamer1-plugins-bad-free and gstreamer1-plugins-bad-free-extras. Then three of the plugins are split out individually, so we have five subpackages total for gst-plugins-bad. But if we wanted to maximize minimization (heh), we could instead have 130something subpackages for each of the individual plugins shipped by gst-plugins-bad. Could also leave everything else alone, split just gsttranscoder out separately. Or maybe could move it from -bad to one of the other packages, -good or -base. (I'm not an expert in why each plugin is where it is currently, but plugins in -bad are intended to eventually move to -good or -ugly.) It's really up to the GStreamer maintainers. Personally, I'd say if you're interested in minimization, the most important step is to not depend on WebKitGTK in the first place, rather than try to reduce its dependencies. But whatever. > Is there any possibility we > could have a build of webkitgtk without any of the AV support, for cases > where all we need is a library that can render HTML/XML without multimedia? Definitely not. It takes way too long to build this package because we have to build it three times already. I want to build it only twice, not four or five or six times.
Also, you're going to lose all of these gains when anaconda web installer switches to Firefox. The Firefox RPM alone is 240 MB.
Sure, well, it's a tricky area. But there's a clearly definable generic need here that is missing: a reasonably-scoped library for displaying non-multimedia HTML/XML content. The new installer needs that. The help content of the current installer needs that. There used to be gtkhtml, but there isn't any more; webkitgtk seems to be the only game in town, but then you wind up with all this support for recording video when all you want is to render an HTML page. There are probably other things with the same need; it doesn't seem like an outlandish need. For the help, at least, we could I guess look at putting it into some other marked-up text format and finding some alternative library for displaying that. But the whole point of the new installer is to use HTML, yet - as you point out - apparently the only choices we have for rendering it are all way overweight because they support a bunch of stuff it does not need, and it seems like this is only going to get worse, because webkitgtk and Firefox (and any other rendering engines I can think of) all seem to be on the same track of adding more and more capabilities without caring about making them separable for use cases which don't want or need them...
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
Why is this bug against gstreamer?
See comments 1 and 3.
(In reply to Michael Catanzaro from comment #3) > (In reply to Adam Williamson from comment #2) > > Can we get any more useful detail than that? What is the thing webkitgtk > > needs to link to now that it didn't need before, > > gsttranscoder from gstreamer1-plugins-bad-free The plugin or the library?
If I'm following, does this mean webkitgtk could now be changed to depend on gstreamer1-plugins-bad-free-libs instead?
Library dependencies shouldn't be explicitly listed. If it's just linking against libgsttranscoder, then the PR would prevent gstreamer1-plugins-bad-free and its dependencies from being pulled in simply by virtue of linking against it. If however one of bad-free's many *plugins* are being used, that PR wouldn't change anything.
The hard dependency is indeed only on libgsttranscoder, and the plugins are pulled in by Recommends, not by Requires, so they should no longer be a hard dependency after this GStreamer packaging change.
FEDORA-2023-bdd7edbd91 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-bdd7edbd91
FEDORA-2023-bdd7edbd91 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-bdd7edbd91` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-bdd7edbd91 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-bdd7edbd91 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.