Proposed as a Freeze Exception for 32-beta by Fedora user chrismurphy using the blocker tracking app because:

 Workstation WG agreed to automatically install the OpenH264 codec, by using a cross-repo recommends dependency (possibly from totem). To set this up, we will first need to have the OpenH264 repo enabled by default. This will automatically install the codec along with the first package updates.
https://pagure.io/fedora-workstation/issue/84#comment-625721

To follow up a bit from the meeting here: it seems releng wasn't entirely aware of what Chris meant by "In order to implement this in a way that complies with current policy, composes must have this repo *disabled* so that weak dependencies do not pull in software into the media and install trees distributed by Fedora." We have approved this as an FE in theory, but I don't intend to actually request the update go stable until it's very clear that everyone on Workstation WG and releng sides are on the same pages about the consequences of the change, the potential problem, and that whatever changes necessary on releng side have been made.

AIUI the issue is that if we run composes with the repo enabled, soft dependencies may cause packages from it to be pulled into *the install trees* and/or *the composed images*, and we do not want that to happen. So Chris suggested that somehow fedora-repos should have the repo enabled and the composed images should have that fedora-repos, with the repo enabled, installed - but *during the compose process itself* the repo should not be enabled. Can releng please look into the issue and determine whether that's actually necessary and, if so, whether it can be done? Thanks.

(We might want to try making this change on Rawhide first and firing a Rawhide compose as a kind of trial balloon, if we're not sure about the consequences...)

Discussed during the 2020-03-02 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedFreezeException" was made as it makes sense to change this in Beta if we intend to have it changed for Final, but we will not actually push the update stable until we're sure workstation WG and releng are on the same page about the consequences and any necessary changes to ensure the result is as intended.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-03-02/f32-blocker-review.2020-03-02-17.00.txt

https://pagure.io/releng/issue/9246

unfortunately this change got bundled with the fix to remove the dep on repos-rawhide, it would've been good to have those separate. Fortunately, though, discussion seems to indicate everyone's fairly happy this change should be safe, so we'll go ahead and pull it in.

fedora-repos-32-0.7 has been pushed to the Fedora 32 stable repository. If problems still persist, please make note of it in this bug report.

Is it expected that the repo is enabled in rawhide base container images now, so potentially used during container image builds? The https://pagure.io/releng/issue/9246 says

  We might accidentally ship OpenH264 codec packages on our media, which would be... bad.

but can't our users gets to the same bad situation by mistake, getting something pulled into their container images and distributing it?

I'm not sure how they would do that 'accidentally'... they would still need to 'dnf install -y openh264...' or the like no?

Perhaps we could look at disabling it again there, I am not sure what would be involved in that however.

My understanding is that that Accidentally refers to packages pulled into dnf transactions via weak dependencies.

(In reply to Jan Pazdziora from comment #7)
> Is it expected that the repo is enabled in rawhide base container images
> now, so potentially used during container image builds?

This will never happen since the repo that the build uses never will have openh264 stuff in it.

The repo that we use for building container images are generated from a base koji tag, for ex: f33, where as openh264 stuff are built in a side tag f33-openh264.

Those builds will never end up in the base koji tag and will never get installed during the build process.

My concern is not the Fedora base container images. My concern is the images that people will build from the Fedora base images, and the risk that something from the openh264 repo will get pulled into those images.

(In reply to Jan Pazdziora from comment #11)
> My concern is not the Fedora base container images. My concern is the images
> that people will build from the Fedora base images, and the risk that
> something from the openh264 repo will get pulled into those images.

As Kevin mentioned that should not really be accidental since you would have to run "dnf install -y openh264", so I don't think this is will cause to much risk.

One thing that will be more annoying is that every build will now take longer, since we know have 1 more repo metadata to download during a 'dnf install' command, since container are built and rebuilt a lot that might be something we want to try to mitigate.

We've had reports this morning that people are getting prompted to import a GPG key which seems to be related to this repo being added - see https://bugzilla.redhat.com/show_bug.cgi?id=1814596 for e.g...