> 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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
