One solution to reduce the time taken by client side layering and
those issues mentioned
above is to move the package overrides back to the server side by using a layering
approach similar to the one used to build containers. This is the goal of this change:
https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable. It enables users to
make custom builds of Silverblue/Kinoite with their own selection of packages and
changes
and then to distribute them as an image to their systems, getting the full benefits of
pure image based updates back if they don't do any local changes anymore.
We can't do that on Fedora infrastructure, though, because we cannot distribute
OpenH264. It would have to be done by Cisco. Seems like a no-go.
But it might be OK to just not run fedora-autofirstboot for Silverblue/Kinoite. Thing is,
system multimedia codecs are really a lot less important on Silverblue/Kinoite than they
are on traditional desktops. What users really care most about is whether their
_applications_ can play videos. That's a solved problem for anything using Flathub.
For Fedora Flatpaks, the solution would have to be Flatpak extensions hosted by Cisco:
overlaying OpenH264 on the host system won't actually accomplish anything useful. Even
if you need it for a command line tool like ffmpeg, you're probably using a toolbx
container for that, so again it's just not nearly so important on the host system.