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-0008.html>