Bug 1807679 - enable fedora-cisco-openh264 repo by default
Summary: enable fedora-cisco-openh264 repo by default
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-repos
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mohan Boddu
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: F32BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2020-02-26 22:37 UTC by Chris Murphy
Modified: 2020-03-18 20:02 UTC (History)
11 users (show)

Fixed In Version: fedora-repos-32-0.7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-06 20:49:34 UTC
Type: Bug


Attachments (Terms of Use)

Description Chris Murphy 2020-02-26 22:37:35 UTC
The Fedora Workstation WG has decided that fedora-cisco-openh264 repo should be enabled by default for Fedora 32 and later.

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.

PR to merge
https://src.fedoraproject.org/rpms/fedora-repos/pull-request/52#request_diff



References:

Automatically install the OpenH264 codecs (WG discussion and decision)
https://pagure.io/fedora-workstation/issue/84

Comment 1 Fedora Blocker Bugs Application 2020-02-26 22:42:10 UTC
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

Comment 2 Adam Williamson 2020-03-02 18:49:08 UTC
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...)

Comment 3 Geoffrey Marr 2020-03-02 20:23:04 UTC
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

Comment 4 Chris Murphy 2020-03-06 07:20:30 UTC
https://pagure.io/releng/issue/9246

Comment 5 Adam Williamson 2020-03-06 20:36:33 UTC
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.

Comment 6 Fedora Update System 2020-03-06 20:49:34 UTC
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.

Comment 7 Jan Pazdziora 2020-03-09 09:59:41 UTC
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?

Comment 8 Kevin Fenzi 2020-03-10 17:57:06 UTC
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.

Comment 9 Jan Pazdziora 2020-03-10 18:03:32 UTC
My understanding is that that Accidentally refers to packages pulled into dnf transactions via weak dependencies.

Comment 10 Mohan Boddu 2020-03-10 18:31:38 UTC
(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.

Comment 11 Jan Pazdziora 2020-03-10 19:58:00 UTC
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.

Comment 12 Clement Verna 2020-03-12 14:18:50 UTC
(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.

Comment 13 Adam Williamson 2020-03-18 20:02:41 UTC
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...


Note You need to log in before you can comment on or make changes to this bug.