EPEL 10 bikeshedding: dist tag

[carlwgeorge (Carl George)]

@salimma

Use the RHEL / Stream terminology (el10 for leading branch, el10_Y for rebuilds meant for 10.Y) for consistency – if RHEL / Stream were to change their dist tag for the leading branch then we follow suit. There are cons to this approach - having to bump the leading branch - but this makes the contribution process to Stream and EPEL similar so probably better in the long run

This idea is starting to grow on me. Matching how RHEL dist tags work would be the least surprising thing for users. I think this would result in most packages having .el10 dist tags, with just a few with .el10_x dist tags. However, I’m still concerned about the NVR sorting issue I mentioned here. The only potential mitigation I can think of would be to create a policy for EPEL that states it is the maintainers’ responsibility to ensure that the leading branch always has a higher version or release than older branches. I’m skeptical such a policy would be regularly followed, but perhaps upgrade path problems would be rare enough that we can manage.

[kevin (Kevin Fenzi)]

Well, just making a policy wouldn’t do much I agree. We would need some way to check it and enforce or at least notify about it. This could be something similar to the ‘fails to install’. ie, find these and file a bug on it?

[carlwgeorge (Carl George)]

Yeah that could work, but I still find that less appealing than just choosing a dist tag scheme that prevents it from happening entirely. It also might be worthwhile figuring out what the long term plan is for @tdawson’s willit scripts before we considering adding more “fails to install” type checks (do we add them in the willit scripts or alongside the Fedora FTI tooling?).

[carlwgeorge (Carl George)]

@carlwgeorge

IIUC, the “right bump” you’re referring to is the optional .<minorbump> after the dist tag. This is part of the packaging guidelines. Banning it’s usage in EPEL doesn’t seem appropriate to me when it’s allowed and used in both Fedora and RHEL. Even if we did, that would lead to confusion for folks that believe they understand how the versioning guidelines work. A big goal of the EPEL 10 plan is to reduce confusion.

I had a follow up thought to my previous reply about “right bumps” in dist tags.

If we go with option 1 or option 3, that will look like this:

• 1%{?dist}.1 → 1.el10_0.1

If we go with option 2, that will look like this:

• 1%{?dist}.1 → 1.el10~0.1

Personally, my brain parses the first dist tag as el10_0 and 1 separated by a period, but parses the second as el10 and 0.1 separated by a tilde. Of course the 10 and 0 are related and the trailing minor bump is independent, so the underscore format lends itself better to that understanding in my opinion.

[tdawson (Troy Dawson)]

I’m sorry for being late to comment on this thread.
With the revised version of Option 2 (.el10~2) I’m currently torn between Option 1 and Option 2. I don’t like Option 3. Here are my thoughts on them.

Option 1

• (pro) I really like that I can see what release a package was built against. As a package maintainer, that’s a big plus.
• (con) I worry that end users (and some maintainers) are going to complain when a package has been built against _0 and we’re at 10.6, even though the package works perfectly fine.
• (pro) Simple and easy to understand upgrade path.

Option 2

• (pro) I like the clean-ness of .el10 for majority of packages. It just feels correct.
• (pro) I won’t have users complaining that I need to recompile my older package when we are on 10.6, even though the package works perfectly fine.
• (pro) Correct upgrade path.
• I believe the majority of users won’t notice when packages go from 1.2.el10~2 to 1.2.el10. All they usually care about is if things update without error. A quick explanation (web page) will let those who care know why things are the way they are.

Option 3

• (con) There is the possibility that upgrades will not upgrade correctly. This is major and my mind can’t get around it. So my mind doesn’t even allow this to be thought about.

Summary: I am currently fine with either Option 1 or Option 2. I have no strong preference for one or the other. I am against Option 3.

[carlwgeorge (Carl George)]

@tdawson

(con) I worry that end users (and some maintainers) are going to complain when a package has been built against _0 and we’re at 10.6, even though the package works perfectly fine.

I can understand where you’re coming from on this. You got me thinking about this happening in RHEL. Here are some examples of packages in RHEL 8.7 that are currently the newest available:

• authd-1.4.4-5.el8_0.1
• libwmf-0.2.9-8.el8_0
• dotnet3.0-3.0.103-1.el8_1
• icu-60.3-2.el8_1
• libcacard-2.7.0-2.el8_1
• python-requests-2.20.0-2.1.el8_1
• libcroco-0.6.12-4.el8_2.1
• nghttp2-1.33.0-3.el8_2.1
• dbxtool-8-5.el8_3.2
• libexif-0.6.22-5.el8_3
• mariadb-connector-c-3.1.11-2.el8_3
• stunnel-5.56-5.el8_3
• xterm-331-1.el8_3.2
• dotnet-2.1.526-1.el8_4
• gcc-toolset-10-elfutils-0.182-6.el8_4
• gcc-toolset-10-valgrind-3.16.0-6.el8_4
• gupnp-1.0.6-2.el8_4
• libdb-5.3.28-42.el8_4
• libuv-1.41.1-1.el8_4
• lz4-1.8.3-3.el8_4
• pcsc-lite-ccid-1.4.29-5.1.el8_4

Despite this being common in RHEL, I can’t recall a single time I’ve seen a user complain about it. Perhaps there have been complaints I didn’t see. Perhaps it will be more common if we use that dist tag pattern for all EPEL packages. But I suspect that most users don’t look at this, and those that do understand that packages aren’t always updated in every OS minor version.

[neil (Neil Hanlon)]

I’m largely in agreement here, I don’t think it’s too much of an issue, and provides actually good information if/when you do run into a problem, at least in my experience. It can be useful to know “oh, we haven’t rebuilt this since 10_0… maybe there’s a bug/update/etc”

I like 3 the most, if people don’t like 1.

[carlwgeorge (Carl George)]

Today at the EPEL Steering Committee meeting, we conducted a ranked-choice vote of the dist tag options for EPEL 10.

1. .el10_<minor> in all branches (7 first choice votes)
2. .el10 in leading branch, .el10~<minor> in non-leading branches (5 first choice votes)
3. .el10 in leading branch, .el10_<minor> in non-leading branches (1 first choice votes)

Option 1 was the winner. The full results can be viewed here:

Ranked Choice Vote Calculator App

The meeting log can be viewed here:

epel - Logs