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(a)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:
>>
>>
>> 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
>>
> 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...
>
>