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!