How to remove builds from EPEL 9 Next?

[Miro Hrončok]

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?

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Neal Gompa]

On Fri, May 27, 2022 at 8:00 AM Miro Hrončok <mhroncok(a)redhat.com&gt; 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...


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Ben Beasley]

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&gt; 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...
>
>

[Troy Dawson]

On Fri, May 27, 2022 at 5:38 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Fri, May 27, 2022 at 8:00 AM Miro Hrončok
> <mhroncok(a)redhat.com&gt; 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.
>
>  
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