Hey EPEL folks,
The python-Rtree package was unable to build in EPEL 9 before RHEL 9.0 GA, as the frozen set of packages from CentOS Stream made it segfault during build.
So it was build in EPEL 9 Next instead, as python-Rtree-1.0.0-2.el9.next.
Now, it builds in regular EPEL 9 successfully (as the segfault was fixed in the meantime).
So, we should probbaly build and ship the package in EPEL 9. But we should also remove/obsolete/replace the EPEL 9 build somehow.
I suppose there are multiple options here:
1. bump and build in epel9, so the EVR is higher, do nothing with epel9-next 2. build in epel9, untag the old epel9-next build
What is the general guideline in this situation?
Related, but not necessarily blocking question: Should EPEL 9 Next be purged after each RHEL 9.Y release and all the purged builds built in regular EPEL 9 instead?
On Fri, May 27, 2022 at 8:00 AM Miro Hrončok mhroncok@redhat.com wrote:
Hey EPEL folks,
The python-Rtree package was unable to build in EPEL 9 before RHEL 9.0 GA, as the frozen set of packages from CentOS Stream made it segfault during build.
So it was build in EPEL 9 Next instead, as python-Rtree-1.0.0-2.el9.next.
Now, it builds in regular EPEL 9 successfully (as the segfault was fixed in the meantime).
So, we should probbaly build and ship the package in EPEL 9. But we should also remove/obsolete/replace the EPEL 9 build somehow.
I suppose there are multiple options here:
- bump and build in epel9, so the EVR is higher, do nothing with epel9-next
- build in epel9, untag the old epel9-next build
Generally, you bump to raise the EVR and then the automation Troy has can untag everything in EPEL next that's lower than what's in EPEL.
What is the general guideline in this situation?
Related, but not necessarily blocking question: Should EPEL 9 Next be purged after each RHEL 9.Y release and all the purged builds built in regular EPEL 9 instead?
Yes, please, for the sake of my mirror hosting space...
Thanks for asking this question (and for the heads-up that the problem is fixed). I’ll do as Neal suggested for python-Rtree, as well as a couple of other packages (python-mapbox-earcut, iml) that were in a similar situtation.
– Ben
On 5/27/22 08:37, Neal Gompa wrote:
On Fri, May 27, 2022 at 8:00 AM Miro Hrončok mhroncok@redhat.com wrote:
Hey EPEL folks,
The python-Rtree package was unable to build in EPEL 9 before RHEL 9.0 GA, as the frozen set of packages from CentOS Stream made it segfault during build.
So it was build in EPEL 9 Next instead, as python-Rtree-1.0.0-2.el9.next.
Now, it builds in regular EPEL 9 successfully (as the segfault was fixed in the meantime).
So, we should probbaly build and ship the package in EPEL 9. But we should also remove/obsolete/replace the EPEL 9 build somehow.
I suppose there are multiple options here:
- bump and build in epel9, so the EVR is higher, do nothing with epel9-next
- build in epel9, untag the old epel9-next build
Generally, you bump to raise the EVR and then the automation Troy has can untag everything in EPEL next that's lower than what's in EPEL.
What is the general guideline in this situation?
Related, but not necessarily blocking question: Should EPEL 9 Next be purged after each RHEL 9.Y release and all the purged builds built in regular EPEL 9 instead?
Yes, please, for the sake of my mirror hosting space...
On Fri, May 27, 2022 at 5:38 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, May 27, 2022 at 8:00 AM Miro Hrončok mhroncok@redhat.com wrote:
Hey EPEL folks,
The python-Rtree package was unable to build in EPEL 9 before RHEL 9.0
GA, as
the frozen set of packages from CentOS Stream made it segfault during
build.
So it was build in EPEL 9 Next instead, as python-Rtree-1.0.0-2.el9.next.
Now, it builds in regular EPEL 9 successfully (as the segfault was fixed
in the
meantime).
So, we should probbaly build and ship the package in EPEL 9. But we should also remove/obsolete/replace the EPEL 9 build somehow.
I suppose there are multiple options here:
- bump and build in epel9, so the EVR is higher, do nothing with
epel9-next
- build in epel9, untag the old epel9-next build
Generally, you bump to raise the EVR and then the automation Troy has can untag everything in EPEL next that's lower than what's in EPEL.
If you have a package, or list of packages that you want me to untag out of epel9-next, let me know. I think either (1) or (2) is a valid way to do things. 1 - If you bump and build in epel9 and just leave it in epel9-next, it will get cleaned up next time I "purge" the epel9-next repo. 2 - If you build in epel9, and untag it in epel9-next, that's great too. Just know that CentOS Stream users that already had the -next packages installed, won't automatically get updated. That may, or may not, matter to you.
What is the general guideline in this situation?
Related, but not necessarily blocking question: Should EPEL 9 Next be
purged
after each RHEL 9.Y release and all the purged builds built in regular
EPEL 9
instead?
Yes, please, for the sake of my mirror hosting space...
Yes, I plan on doing this at each release. And I did it before the RHEL 9.0 release. I sent an email making sure everyone was ok with what I was removing. It isn't a complete purge. - I checked to see if there were any epel9-next packages that had the same, or older NVR's. - I verified that the regular epel9 packages in that list were installable in CentOS Stream 9. - I sent an email to epel-devel to double check. That cleared out everything but two packages.
epel8-next numbers are fairly small, and I know that about half of them are for RHEL 8.7, but I'll give it a pass as well, see what can be cleared out. Troy
epel-devel@lists.fedoraproject.org
-
Ben Beasley -
Miro Hrončok -
Neal Gompa -
Troy Dawson