[CentOS-devel] Community build services and EPEL8

Neal Gompa

ngompa13 at gmail.com
Sat Jul 13 12:14:37 UTC 2019


On Sat, Jul 13, 2019 at 8:06 AM Kaleb Keithley <kkeithle at redhat.com> wrote:
>
> 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.
>

The only architecture in CentOS not built in EPEL is armv7hl. EPEL
builds ppc64le stuff all the time, since that's a RHEL architecture.

>>
>> > 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_.
>

Ugh, I hate these hacks... I wish we had sticky vendors in DNF for
this, because playing EVR games is a poor experience for users...



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



More information about the CentOS-devel mailing list