<div dir="ltr"><div dir="ltr">On Sat, Jul 13, 2019 at 6:57 AM Neal Gompa <<a href="mailto:ngompa13@gmail.com">ngompa13@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Jul 13, 2019 at 5:03 AM Niels de Vos <<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>> wrote:<br>
> On Fri, Jul 12, 2019 at 03:31:05PM -0400, Stephen John Smoogen wrote:<br>
> > On Fri, 12 Jul 2019 at 13:24, Niels de Vos <<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>> wrote:<br><br>
To me, that's not a good excuse. You already are doing these builds in<br>
CBS, and it's easy because you're already here. Getting involved in<br>
EPEL isn't hard, and working with EPEL folks to get things (re)built<br>
as needed isn't difficult.<br></blockquote><div><br></div><div>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.)<br></div><div><br></div><div>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.)<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The only problems come up when there's a CentOS-only architecture.<br>
EPEL has never enabled CentOS architectures that don't exist in RHEL.<br></blockquote><div><br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> However, it would be ideal if EPEL and repositories from SIGs can<br>
> co-exist without causing conflicts. I'd support any efforts for making<br>
> this possible.<br>
<br>
I sure hope so, since EPEL is a pretty popular addon repo for EL<br>
users. I've heard of people saying EL is useless without it. :P<br></blockquote><div><br></div><div>There are certainly a lot of anecdotes around this. I don't find it to be the case for the things I work on.</div><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The situation with SIGs in CentOS 7 is something I'd like to not see<br>
again for CentOS 8. The subtle breakages caused by SIGs doing<br>
different builds of EPEL packages made things more painful at times.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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_.</div><div><br></div><div>--</div><div><br></div><div>Kaleb</div><div><br></div><div><br></div></div></div>