releng

#12217 Revert changes to rpms/stgit epel9 branch
Closed: It's all good by kevin. Opened by fmaurer.

Closed: It's all good
Reopen Issue
  • Describe the issue

During a recent update of dependencies of stgit (https://src.fedoraproject.org/rpms/stgit), accidentally the epel9 branch in dist-git was updated to the latest version (2.4.7) as well. The update was from 79ebf9c ("Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild") to 8c52838 ("Update gix dependency to 0.63"). The update was never built.

This update of dist-git should not have happened. It would constitute a major version jump from stgit 1.5 (written in python) to stgit 2.4.7 (written in rust). I don't think that's acceptable in the EPEL policies. I tried resetting the branch in dist-git myself, but seems like I don't have permission to do that. Can you reset the epel9 branch to 79ebf9c ("Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild") which matches the currently built version of the package in epel9?

  • When do you need this? (YYYY/MM/DD)

Before the next update to stgit in epel9 happens. This almost never has updates, so it's low priority.

  • When is this no longer needed or useful? (YYYY/MM/DD)

When epel9 is EOL.

  • If we cannot complete your request, what is the impact?

We can not provide updates to stgit in epel9 without introducing a major version jump that is not needed.

We don't re-write history in package git repos.

Just make a revert commit and push that. It will of course diverge from rawhide then, but such is life.

Metadata Update from @kevin:
- Issue tagged with: low-gain, low-trouble

It might also be fine to update EPEL 9 after all, just going through the incompatible updates policy steps for EPEL should be enough. But that's up to you.

Hm, I assumed incompatible updates are only okay for security, etc. reasons, but that's not the case (yet). On the other hand, the CLI of v2 is not incompatible to v1, the commands mostly work the same way. Only the internals changed heavily, but I'm not sure if that counts.

But if we determine "v1 will never even see security fixes" a valid reason to do the update in EPEL 9, I'm fine going through the incompatible update steps.

I'd say it's worth discussing with the epel sig ( https://pagure.io/epel )

Let us know if we can help any further.

Metadata Update from @kevin:
- Issue close_status updated to: It's all good
- Issue status updated to: Closed (was: Open)
Metadata
None

low-gain low-trouble

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.