[EPEL-devel] To buildroot, or not to buildroot

[Troy Dawson]

This was originally "python-gevent and pytest-cov in el9"
But I wanted to talk about and discuss this paragraph from Carl on it's own.

On Fri, Sep 24, 2021 at 7:43 PM Carl George <carl(a)redhat.com&gt; wrote:

>  On a related note, EPEL 9 Next _is_ being set up to build against
> the
>  CentOS Stream 9 buildroot.  This works for EPEL Next because it
>  explicitly targets the next minor release of RHEL (i.e. CentOS
>  Stream).  This will allow more packages to be built, at the cost of
>  potentially confusing packagers when their package builds successfully
>  for EPEL 9 Next but not for EPEL 9.  EPEL 8 Next currently builds
>  against published CentOS Stream 8 content.  If things go well with
>  EPEL 9 Next using the CentOS Stream 9 buildroot, EPEL 8 Next may
>  switch to using the CentOS Stream 8 buildroot in the future.
>  
Although I'm not against using the CentOS Stream buildroot for epel9-next,
we're already starting to see large sections of KDE that WILL be buildable
against the buildroot but WILL NOT be buildable against plain epel9.[1]

This isn't a matter of "confusing packagers", it's a matter of major
delays
when we switch from epel9-next to epel9.

I'll have to file all those "please move these packages into CRB" bugz
after RHEL9 is out.
I'll also have to request "branch and builds" for all those packages in the
buildroot that are ONLY in the buildroot.
And then request the dependencies for those packages.  And so forth.

And that's just the packages I am working on.  I can't speak for anyone
else.

[possible solution]

If we are going to have the CS buildroots in any of our epel-next repo's,
we need to develop a "missing build-dep" service.

Something that regularly checks to make sure epel9-next packages are built
against packages that will be in epel9.  And if they are not buildable,
let's the package maintainer know.
And let Red Hat know as well.
A nice list that people can easily look at and see which "missing
build-dep" is being used, and by what packages.

Troy

p.s.  I'm sorry if this email sounds accusatory and/or negative.  I've
re-written it twice and it still sounds negative to me.  Possibly cuz I'm
showing the bad things that can/will happen.  But I want to put the
emphasis on the possible solution.  More of a "hay, let's see if this would
work."  So, if someone finds this hurting their feelings, I'm sorry.  At
this point I just need to send it, or I never will.

[1] - https://bugzilla.redhat.com/show_bug.cgi?id=2009831