Closed kanru closed 3 weeks ago
You now need to remove the noopenh264
package when layering the openh264
one:
$ rpm-ostree override remove noopenh264 --install openh264 --install mozilla-openh264
Isn't noopenh264
obsolete though? Why is it included in the first place?
No it is a placeholder which is obsoleted by the real openh264 package in the cisco repo.
This seems like a reasonable candidate for CommonBugs: maybe that requires a bugzilla or can we link to this issue?
@OptimoSupreme noopenh264 provides OpenH264 API through stubs that can be built against. (eg by gstreamer plugin and ffmpeg) The idea is that you would then drop-in OpenH264 to provide the actual implementation.
@nanonyme so I guess my question is when would you actually need the noopenh264 package? From what I found and what was said before, I needed to remove the package just to install openh264.
It's needed as a dependency of the packages I mentioned before. They will load the API's with stubs and gracefully report OpenH264 is not supported and move on. There isn't really any other problem here than that depsolver refuses to remove the conflicting noopenh264 in favour of openh264 without manual action from user.
I think this is a limitation of rpm-ostree? Though I can't find any existing issue reported there, which makes me wonder. (The closest issue might be coreos/rpm-ostree#4533). Perhaps it is because openh264 is from a different repo? Or more likely rebases can't handle obsoletes perhaps?
In fact it is not just rebase, even after upgrading https://github.com/fedora-silverblue/issue-tracker/issues/536#issuecomment-1974780009 is still needed to overlay openh264
I am still not clear how noopenh264 gets pulled into SB40 though? In retrospect it seems better to have excluded it but I think it is too late for that for the GA iso at least. I feel it still makes sense for updates though.
I started writing a rpm-ostree issue, but this is probably expected behavior, right?
My educated guess is it gets pulled in as dependency of gstreamer OpenH264 plugin or ffmpeg.
IMHO this is a missing feature, unclear where. Probably rpm-ostree.
It seems like it gets pulled as a weak dep of libavcodec-free
(which gets pulled in by gstreamer1-plugin-libav
).
We also ship libavcodec-free
in f39 and libopenh264.so.7()(64bit)
is also a weak dep there.
Anyway, opened https://pagure.io/workstation-ostree-config/pull-request/508 (and an f40 backport) which I think should fix this but I didn't test it yet.
Make sure to test trying to view OpenH264 content doesn't result in a crash afterwards but instead failure on missing codec.
At some point, libavcodec-free
may start linking against noopenh264
in lieu of using a downstream dlopen patch. If that happens, it will no longer be optional, so excluding it from the image now may just be delaying the inevitable. I'm not certain what their plans are though.
From my perspective, rpm-ostree's behavior is correct; it shouldn't automatically override the base image for any reason. Maybe it would be possible to make openh264
work like libavcodec-freeworld
where it's parallel-installable with noopenh264
? I don't know if that's worth it just for atomic users, since ideally they wouldn't need to layer it in the first place, but that's pending on flatpak Firefox by default and availability of a Fedora openh264 extension.
The thing is, they both provide same soname libraries. Whatever the setup, it should be so that everything switched to loading OpenH264 library when present. With flatpak runtimes this is simple, the extension can just be mounted on top of noopenh264 like how it's done in freedesktop-sdk.
The thing is, they both provide same soname libraries. Whatever the setup, it should be so that everything switched to loading OpenH264 library when present.
You can achieve that by making openh264 parallel installable putting libopenh264.so.7
in %{_libdir}/openh264/
and dropping an appropriate config into /etc/ld.so.conf.d
.
That might actually even be safer than removal. Then if you have OpenH264 with different soname, video frameworks fallback to noopen264.
Make sure to send all of those suggestions to the noopenh264 maintainers (maybe via a bugzilla) otherwise they likely won't see it here.
I think you mean OpenH264 package maintainers?
Yeah, this was expected. You can't just drop a package in the middle of dep chain without removing all reverse dependencies
So now that this has been figured out, can I ask what the intended method is for adding openh264 functionality to Firefox on a baseline Silverblue is?
It looks like it's unlikely that we'll be able to remove this package from the images so I'll close this issue.
Describe the bug
If mozilla-openh264 was previously layered it prevents rebasing to F40. After removed mozilla-openh264 and rebased to F40, mozilla-openh264 cannot be layered again unless first removing
noopenh264
from the base.To Reproduce Please describe the steps needed to reproduce the bug:
rpm-ostree install mozilla-openh264
Expected behavior Both
mozilla-openh264
andopenh264
should be layered.Screenshots N/A
OS version:
Additional context N/A