epel

#303 Can stgit be updated in epel9
Closed: Won't Fix by fmaurer. Opened by fmaurer.

Closed: Won't Fix
Reopen Issue

A while ago, the epel9 branch of stgit was accidentally updated, now including a major version jump (from 1.5 to 2.4). I asked for this to be reverted by releng in https://pagure.io/releng/issue/12217 but we don't do that. Instead, they suggested that this may be a candidate for an incompatible update in EPEL.

stgit is a command line application to manage patchsets in git repositories. The major change between v1.x (currently built in epel9) and v2.x (currently in dist-git of epel9) is that the application was rewritten in Rust. The rewrite kept the command line interface mostly equivalent to v1.x, the output of the commands changed though. In general, I expect no issues when a user runs stgit after the update because the CLI is compatible, it's just the internals that are not compatible at all.

I'm aware that this is not a standard incompatible update request. There is no security fix to v1.5 that we can only apply by updating to v2.x, or similar. However, v1.x is not maintained upstream at all anymore, making it very unlikely that there will ever be security fixes for it (despite no software being bug free). With an update to v2.x we have a reasonable chance that we can backport security fixes that might surface in the future.

Do you consider an update of stgit from v1.5 to v2.4.12 (probably) reasonable in epel9? If so, I'm happy to go through the incompatible upgrades process. I just want to have some clarity upfront if this is in scope of the policy at all.

Metadata Update from @carlwgeorge:
- Issue tagged with: meeting

Thanks for reaching out to check. Determining if this is a reasonable upgrade is what the incompat process is for, so let's start that process and see where it goes. Please send an email to epel-devel to bring the idea up for wider discussion. I went ahead and added the meeting tag to this issue to bring it up for awareness (not a vote yet) at this week's steering committee meeting.

For clarification, it's not strictly required for there to be security fixes to permit an incompatible update, that's just the most common scenario. The v1 branch being unmaintained upstream isn't necessarily enough reason to allow this upgrade. Many EPEL packages are in a similar scenario, and we aren't proactively upgrading them without a pressing issue to resolve.

I have a few more questions that could help inform the discussion and decision on this.

  • Has upstream ever identified a release as containing a security fix?
  • Has upstream stated that there won't be any more v1 releases, or is that an assumption?
  • Since v2 was rewritten in rust, are all the build dependencies present in epel9 for this to be able to build successfully?

If the commit was never shipped, why not do a git revert and push that? It might mess up the changelog a bit but that is fixable

Metadata Update from @carlwgeorge:
- Issue untagged with: meeting

Yes, a git revert would just fix this and I'll do that if we are not going the incompatible updates route. It just came up that stgit might be a candidate for the incompatible updates process, so I wanted to check that first before there is a back-and-forth in dist-git.

I'll check the questions you posted (esp. the build) and send an email to epel-devel, thank you!

@fmaurer I never did see this brought up on epel-devel. How did you want to proceed? The easiest thing to do would be to apply a new commit to the epel9 branch that reverts things back to commit of the stgit-1.5-3.el9 build. Here is a PR to do that. If you still want to move forward with an incompat update we can close that PR. I don't see any new v1.* tags upstream, or a v1 branch, so that may be prudent, but it would warrant further discussion via the incompat process.

@fmaurer How did you want to proceed?

Unfortunately, I didn't ever get to testing the build in epel9 and therefore never posted this to epel-devel. That will likely be the case for a bit longer still. So, I decided to stick with the 1.5 version and merged Carl's PR reverting all changes that were accidentally pushed.

Metadata Update from @fmaurer:
- Issue close_status updated to: Won't Fix
- Issue status updated to: Closed (was: Open)

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/epel/steering/issues/303

Please continue any further discussion there.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.