On Sat, Jul 13, 2019 at 5:03 AM Niels de Vos <ndevos@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@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