[CentOS-devel] Community build services and EPEL8

Kaleb Keithley

kkeithle at redhat.com
Sat Jul 13 12:06:33 UTC 2019


On Sat, Jul 13, 2019 at 6:57 AM Neal Gompa <ngompa13 at gmail.com> wrote:

> On Sat, Jul 13, 2019 at 5:03 AM Niels de Vos <ndevos at redhat.com> wrote:
> > On Fri, Jul 12, 2019 at 03:31:05PM -0400, Stephen John Smoogen wrote:
> > > On Fri, 12 Jul 2019 at 13:24, Niels de Vos <ndevos at redhat.com> wrote:
>
> To me, that's not a good excuse. You already are doing these builds in
> CBS, and it's easy because you're already here. Getting involved in
> EPEL isn't hard, and working with EPEL folks to get things (re)built
> as needed isn't difficult.
>

Easy or hard isn't the issue. Niels and I have been "involved in EPEL" in
the past. GlusterFS was in EPEL once, and when it was, it used the EPEL
userspace-rcu packages. (See my earlier email about why GlusterFS was
retired in EPEL.)

I don't remember what the SIG policy was back when when Niels and I (but
mainly Niels) moved GlusterFS to the Storage SIG, and I confess I'm
ignorant about what the policy is now. AFAIK though, we still can't can't
use EPEL to resolve build dependencies in CBS. (Pretty sure I could cobble
up a .spec file that could accomplish it though.)

As an aside, I would assert that if EPEL really wanted to live up to its
stated mission, it would – by now – be building packages for all the CentOS
arches and not just the RHEL arches. Hint, hint.

If using EPEL for build dependencies is solved and the EPEL/CentOS
architecture mismatch is resolved, off hand I can't think of any reason why
we wouldn't be willing to use the EPEL userspace-rcu instead of building
our own. Or I believe we'd at least be willing to consider it.

The only problems come up when there's a CentOS-only architecture.
> EPEL has never enabled CentOS architectures that don't exist in RHEL.
>

Yes, that's definitely an issue. If we have to build userspace-rcu in CBS
for ppc64le, then we might as well build it for the other arches too.


> > However, it would be ideal if EPEL and repositories from SIGs can
> > co-exist without causing conflicts. I'd support any efforts for making
> > this possible.
>
> I sure hope so, since EPEL is a pretty popular addon repo for EL
> users. I've heard of people saying EL is useless without it. :P
>

There are certainly a lot of anecdotes around this. I don't find it to be
the case for the things I work on.

Sometimes it's as simple as knowing what other repos and/or channels are
available and using them. Including even knowing about them in the first
place. E.g. the SCL;  I guess some people just punt and install EPEL rather
than figure out how to get and use SCL.

The situation with SIGs in CentOS 7 is something I'd like to not see
> again for CentOS 8. The subtle breakages caused by SIGs doing
> different builds of EPEL packages made things more painful at times.
>

As far as the conflict between, e.g. the. userspace-rcu in the Storage SIG
versus the one in EPEL, there are are some fairly simple solutions. It
might be as easy as making sure the userspace-rcu in the Storage SIG always
has a higher NVR than the one in EPEL.  That does require some extra
diligence to keep track of what's in EPEL  If the userspace-rcu devs are
careful to maintain API and ABI compatibility, then having a newer
_version_ in the Storage SIG should be okay, in general.

If they're not good about ABI/API compatibility, then we can simply
build/have the same _version_ as what's in EPEL, but build it with a higher
_release_.

--

Kaleb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20190713/d28a5999/attachment-0004.html>


More information about the CentOS-devel mailing list