Hey @kalev

koji taginfo epel10-openh264
Tag: epel10-openh264 [96416]
Arches: 
Groups: 
Tag options:
  mock.package_manager : 'dnf5'
Inheritance:

The tag is created, can you confirm if this looks good? I am not sure about the mock.package_manager : 'dnf5'

Thanks, @jnsamyak! I think it probably makes sense to set mock.package_manager to 'dnf' to match what is used for epel10.0-build. Not sure if it matters at all in practice because of the way the tag is going to be used.

I'm also wondering now if it should be named epel10.0-openh264 instead - I didn't notice earlier that all the existing tags are epel10.0- prefixed and not epel10- . What do you think? Can you ask at releng standup?

I did a first openh264 build for epel10 and I can't tag it into the new tag. The error is:

$ koji tag-build epel10-openh264 openh264-2.4.1-1.el10_0
2024-09-18 12:35:14,667 [ERROR] koji: TagError: Package openh264 not in list for epel10-openh264

I guess the new tag should have inheritance set from epel10.0 to get the package list correctly set?

I'm not 100% sure if this tag should be epel10-openh264 or epel10.0-openh264.

@kalev Can you tell me more about "the way the tag is going to be used"? I'm specifically interested in how its usage will differ from the regular epel10.x tags, as well as details about how often it's expected to be built, and what libraries it is expected to link against. Will it be possible for an openh264 that was built against RHEL 10 to stop working on CentOS Stream 10 based on a library change planned for the next RHEL minor version?

Some open ended, not yet fully formed thoughts about each approach:

• epel10-openh264
  • only make the tag once
  • need to figure out a non-standard tag inheritance (possibly changing the inheritance to each new minor base tag every six months)
  • possible ongoing confusion due to not matching the rest of the epel10 tagging structure
• epel10.0-openh264
  • consistent with the rest of the epel10 tagging structure
  • need to create future minor version tags every six months
  • the same build can have tags for multiple minor versions, no need to rebuild just for that

@kalev, Any thoughts on carl's comment?

Sorry for the delay in replying to this!

The tag is used to hold openh264 builds that would otherwise get garbage collected. openh264-2.4.1-1.el10_0, https://koji.fedoraproject.org/koji/buildinfo?buildID=2548424 is an example - I did it last week and looks like it's already tagged with trashcan. I'll go and untag it from trashcan for now.

The process around openh264 is that I do the builds, and releng generates repo metadata that is shipped in https://codecs.fedoraproject.org/ and sends the rpms for hosting to Cisco's. So releng is the actual user for the tag.

As for dependencies, openh264 itself doesn't have more than glibc and libstdc++, but we also ship gstreamer1-plugin-openh264 in the same repo, and that one links to various gstreamer1 libraries. gstreamer1-plugin-openh264 might make sense to get shipped as part of RHEL base in the future - in that case it would get dropped from Cisco's hosting for future builds.

I think gstreamer1-plugin-openh264 possibly moving to RHEL is a case that would benefit from
epel10.x-openh264 repo structure? This way, e.g. epel10.0 could ship the gstreamer plugin and a future version could drop it, without regressing things from 10.0 users.

Would releng be OK with having to generate new repo metadata for the codecs repo for each epel10.x tag in the future?

Would releng be OK with having to generate new repo metadata for the codecs repo for each epel10.x tag in the future?

Thinking about this some more, I think it would be just copying the metadata to a new directory for each epel 10.x branch, and not necessarily even regenerating it.

Yeah, I would think that should be fine. It's only every 6 months and we can hopefully add it to other steps we have to take for epel minor releases.

@kalev, for now as per the discussion, should I just edit the dnf5 to dnf right (is there anything else), and we can work on a request for every time a minor release happens we can create these?

@jnsamyak No, I think the discussion concluded with that we should delete this tag and create a new one with the other naming scheme.

Can you
(1) delete epel10-openh264 tag, and
(2) create epel10.0-openh264 tag, and set the new tag's mock.package_manager to 'dnf', and (more importantly) set the tag to inherit from epel10.0 so that it gets the package list correctly set.

I think it should be completely safe to just delete epel10-openh264 as it's been completely unused so far.

Oh yes, I deleted the older tag, created the new one, add the inheritance of epel10.0 to it, and set the mock.pckage_manager to dnf!

Here's the taginfo:

koji taginfo epel10.0-openh264                              
Tag: epel10.0-openh264 [97846]
Arches: 
Groups: 
Tag options:
  mock.package_manager : 'dnf'
Inheritance:
  0    .... epel10.0 [93217]

Does this seem okay? Or, do you need me to add more things to it?

Looks all good to me. Thanks, @jnsamyak and everybody else who chimed in!

I filed https://pagure.io/releng/issue/12385 for next steps to send the EPEL 10 openh264 build to Cisco.