F40 cannot layer mozilla-openh264

[kanru]

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:

1. Run rpm-ostree install mozilla-openh264

error: Could not depsolve transaction; 1 problem detected:
 Problem: package noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64 from @System conflicts with openh264 provided by openh264-2.4.0-2.fc40.x86_64 from fedora-cisco-openh264
  - package openh264-2.4.0-2.fc40.x86_64 from fedora-cisco-openh264 obsoletes noopenh264 < 1:0 provided by noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64 from @System
  - package mozilla-openh264-2.4.0-2.fc40.x86_64 from fedora-cisco-openh264 requires openh264(x86-64) = 2.4.0-2.fc40, but none of the providers can be installed
  - conflicting requests

Expected behavior
Both mozilla-openh264 and openh264 should be layered.

Screenshots
N/A

OS version:

State: idle
BootedDeployment:
● fedora:fedora/40/x86_64/silverblue
                  Version: 40.20240301.n.0 (2024-03-01T08:13:52Z)
               BaseCommit: 015c2ff0f7b415c438ce656e2d40ca81d6d3dc6c6b012b95bb4e6c05f46bdfd5
             GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
          LayeredPackages: btrbk fish gnome-boxes starship syncthing
            LocalPackages: ibus-chewing-2.0.0-2.fc39.x86_64

Additional context
N/A

[travier]

You now need to remove the noopenh264 package when layering the openh264 one:

$ rpm-ostree override remove noopenh264 --install openh264 --install mozilla-openh264

[OptimoSupreme]

Isn't noopenh264 obsolete though? Why is it included in the first place?

[juhp]

No it is a placeholder which is obsoleted by the real openh264 package in the cisco repo.

[juhp]

This seems like a reasonable candidate for CommonBugs: maybe that requires a bugzilla or can we link to this issue?

[nanonyme]

@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.

[OptimoSupreme]

@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.

[nanonyme]

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.

[juhp]

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?

[juhp]

In fact it is not just rebase, even after upgrading #536 (comment) is still needed to overlay openh264

[juhp]

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?

[nanonyme]

My educated guess is it gets pulled in as dependency of gstreamer OpenH264 plugin or ffmpeg.

[nanonyme]

IMHO this is a missing feature, unclear where. Probably rpm-ostree.

[jlebon]

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.

[nanonyme]

Make sure to test trying to view OpenH264 content doesn't result in a crash afterwards but instead failure on missing codec.

[chrisawi]

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.

[nanonyme]

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.

[rathann]

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.

[nanonyme]

That might actually even be safer than removal. Then if you have OpenH264 with different soname, video frameworks fallback to noopen264.

[travier]

Make sure to send all of those suggestions to the noopenh264 maintainers (maybe via a bugzilla) otherwise they likely won't see it here.

[nanonyme]

I think you mean OpenH264 package maintainers?

[travier]

https://pagure.io/workstation-ostree-config/pull-request/508#comment-202306

[nanonyme]

Yeah, this was expected. You can't just drop a package in the middle of dep chain without removing all reverse dependencies

[OptimoSupreme]

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?

[travier]

#536 (comment)

[travier]

It looks like it's unlikely that we'll be able to remove this package from the images so I'll close this issue.