EPEL 10 bikeshedding: dist tag

Status update:


The original EPEL 10 proposal thread is getting a bit long, so I’d like to start a new thread to specifically focus further discussion on just one aspect: the dist tags we will use.

Previous feedback was mixed in with other comments in the original thread (which is why I wasn’t able to split the comments cleanly to a new thread), so I’ll try to summarize the possible approaches here.

Option 1

In the original proposal, I suggested using dist tags in the format of .el<major>_<minor> in all branches.

branch dist tag
epel10 .el10_2
epel10.1 .el10_1
epel10.0 .el10_0
  • pro: well understood format
  • pro: consistent across branches and packages
  • pro: always clear which minor version a package was built to be compatible with
  • pro: correct upgrade path
  • con: never uses the simple .el10 dist tag
  • pro: always clear which minor version a package was built against

Option 2

There was a suggestion by @ngompa to keep the leading branch using just the major version, and utilizing tildes to sort other builds correctly.

branch dist tag
epel10 .el10
epel10.1 .el10~1
epel10.0 .el10~0
  • con: tilde character is not as widely understood
  • con: inconsistent across branches and packages
  • con: not always clear which minor version a package was built to be compatible with
  • pro: correct upgrade path
  • pro: allows using the traditional .el10 dist tag for most packages
  • con: not always clear which minor version a package was built against

Option 3

Another approach suggested by @salimma is to use a mix of the above approaches. We would use just the major version in the leading branch, and .el<major>_<minor> in the older branches. This would actually match what RHEL does. The issue with this is that it will lead to upgrade path issues if a maintainer builds from the same commit in multiple branches.

branch dist tag
epel10 .el10
epel10.1 .el10_1
epel10.0 .el10_0
  • pro: well understood format
  • con: inconsistent across branches and packages
  • con: not always clear which minor version a package was built to be compatible with
  • con: upgrade path issues
  • pro: allows using the traditional .el10 dist tag for most packages
  • con: not always clear which minor version a package was built against
2 Likes

My totally unscientific gut reaction is: I kind of hate[1] them both, but I hate[2] Neal’s suggestion slightly less.

I’m not completely sure why. Your original version clearly[3] conveys “hey, this really has a different base”, which is important. And I think they both should work.

It may just be that “plain” .el10 looks prettier.


  1. In the sense of a cranky sysadmin, not actual hate! ↩︎

  2. ibid ↩︎

  3. again in the cranky sysadmin sense, really — nothing is clear about this, but I’ve got years of expectations ↩︎

I think the second one looks nicer, but I kinda hate ~ in package names because it makes them anoying to copy and paste (since most terminals treat ~ as a stop char).

My concern with the tilde option is that while it’s a valid use of RPM sorting characters, it’s not as widely understood. I still run into folks who are learning about tildes in versions/releases for the first time. Using tildes will require more explaining to both users and maintainers.

The underscore approach is an established pattern from RHEL. Anyone who has interacted with a RHEL or similar system has probably seen the underscore format, and even if they haven’t can probably correctly guess what it means and how it will sort. If there was some functional advantage we gained from using tildes it might make it worth the extra explaining, but so far I haven’t seen one.

I agree that aesthetically shorter dist tags like .el10 are nice. The flip side is that I think .el10~10.0 is much, much worse aesthetically. I’d rather have two extra characters in all dist tags, than five extra characters on some dist tags.

RHEL does a mixed approach, using just the major version (e.g. .el9) when a build occurs in the leading branch, and an underscore with the minor version (e.g. .el9_0) when builds occurs in both the leading branch and previous branches. This approach requires making sure that the leading branch has a higher release or version, because if everything else is the same then .el<major>_<minor> sorts higher than .el<major>, which would not sort correctly and provide the correct upgrade path. I think this works well enough in practice for RHEL because there is a higher bar to make commits in older branches, so if a package has gotten any development work done at all the leading branch will already be on a higher release. In EPEL I think it will be much more common for maintainers to keep their commits in sync (fast forward merged) between branches, so we’ll need dist tags that sort correctly when all other values are the same.

Definitely agree with the part about being harder to select in a terminal. Tildes are a useful tool in versions for their intended purpose (sorting pre-release versions before release version), but I would hate the side effects of having them in most releases fields.

I like .el10~10.1 better. Perhaps more specifically, I think it helps visually separate EPEL content from RHEL content on a installed system. Using the RHEL convention of .el<major>_<minor> (e.g. el10_2) is certainly fine, but having something different helps sysadmins and developers differentiate EPEL vs RHEL content on installed systems more quickly.

Kind of an aside, but I think maybe we could convince the terminal people to include ~ in the “word characters” for selection. It’s annoying in URLs too.

Let’s not make that the deciding factor, at least.

In previous conversations @smooge has suggested to me that we start the dist tag with .epel instead of .el for this reason. If we want to make distinguishing EPEL packages from RHEL packages by the dist tag a goal (which I’m not convinced we need to) then I’d much rather go with @smooge’s suggestion than using a completely different pattern involving a character that isn’t widely understood.

Additionally, lack of a tilde in the dist tag wouldn’t guarantee that a package is an EPEL package, because EPEL packages built against the leading branch would have a .el10 dist tag. It wouldn’t be a reliable indicator.

1 Like

A neat idea, but the current reality is that the tilde is a stop character that will result in increased annoyance if we make it a part of most EPEL dist tags. I think ignoring that as a factor is a mistake.

I’m not looking for a bullet-proof comprehensive solution to a minor problem. I’m stating my preference for e10~10.1 and noting a nice side benefit. You asked for people to voice their opinion :slight_smile:

There is another scenario I’d like people to consider with the tilde approach. By using a different pattern for packages built in the leading branch and in previous branches, it will be unavoidable for people to have a set of packages installed with inconsistent dist tag patterns. Consider this order of events:

  • Package foo is built from the epel10 branch against CentOS Stream 10 before RHEL 10.0 is released. This results in a dist tag of .el10.
  • RHEL 10.0 is released, and the foo-1.0-1.el10 package stays in the EPEL 10.0 repo because no changes are needed.
  • Package bar (which has a dependency on foo) is built from the epel10.0 branch against RHEL 10.0. This results in a dist tag of .el10~10.0.
  • A RHEL user runs dnf install bar, and gets the following packages installed:
    • foo-1.0-1.el10
    • bar-1.0-1.el10~10.0

Here is what would happen if we use the established underscore pattern in all branches:

  • Package foo is built from the epel10 branch against CentOS Stream 10 before RHEL 10.0 is released. This results in a dist tag of .el10_0.
  • RHEL 10.0 is released, and the foo-1.0-1.el10_0 package stays in the EPEL 10.0 repo because no changes are needed.
  • Package bar (which has a dependency on foo) is built from the epel10.0 branch against RHEL 10.0. This results in a dist tag of .el10_0.
  • A RHEL user runs dnf install bar, and gets the following packages installed:
    • foo-1.0-1.el10_0
    • bar-1.0-1.el10_0

How does the .el<major>~<major>.<minor> pattern work if a maintainer appends digits after the dist tag, e.g. 1%{?dist}.1 [1]? This would result in a dist tag like .el10~10.0.1 and .el10~10.1.1, which is going to confuse folks even more.


  1. This is explicitly allowed by the packaging guidelines. ↩︎

I agree that changing from .el.epel is unnecessary.

This already happens with RHEL packages, so I don’t know why we should be worried about it with EPEL ones. But we could also do .el<major>~<major>_<minor> if you’d want to avoid the “weirdness” there.

That being said, this case is incredibly rare…

RHEL avoids problems with this by using an underscore instead of a period. I’d don’t know all the history but I would venture a guess that was the reason (or at least a contributing factor) in using underscores in the first place.

Using .el<major>~<major>_<minor> avoids that pitfall, but I still don’t see an advantage to this over the more simple .el<major>_<minor>. Why duplicate the major version and use the tilde at all at that point?

I feel like this is a (small) advantage. Because we don’t do reproducible builds, there might actually be meaningful differences in the resulting package.

Correct me if I’m misunderstanding your point, but I think you mean a meaningful difference between something built against CentOS Stream 10 (when it represents 10.0 content in this example) and something built against actual RHEL 10.0. We’ve repeatedly claimed that CentOS Stream represents the content coming to the next RHEL minor version. We backed it up by building EPEL 9 against CentOS Stream 9 for nearly 6 months, then having users install those packages on RHEL 9.0 when it was released. To my knowledge, there wasn’t a single instance of one of these packages not working correctly due to being built against CentOS instead of RHEL. It’s certainly possible (late soname change in a library perhaps), but I think in practice it will be extremely rare. If it happens we’d handle it as a bug, no different than if a packager made a mistake. I don’t believe that possibility justifies the frequency of dist tag questions we’d get from users in community support channels, both about the tilde in general and about why some packages have the tilde with extra digits and some don’t. Consistently using .el<major>_<minor> is self-evident.

I prefer the first option as I dislike ~ in package names. The first is also consistent with how some EL packages have been versioned in the past anyway so it is familiar.

I don’t get the point here…

The reason why using “_” or “~” in dist was to avoid “.” that can be mixed with the “right bump” in the release tag.

To me what would be an improvement would be to assume not to use “right bump” in EPEL at all and just use plan .el10.0 and so on…

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.

Having read this, I have three preferences:

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

  2. Use ~ as suggested by @ngompa - but don’t repeat yourself: so el10~Y instead of el10~10.Y

  3. In an ideal world the leading branch is tagged for the next minor release, so el10_Y+1 - but this would be confusing without a Fedora-style mass rebuild, and causes us to diverge from Stream