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: > > > > > > > > > Just wondering : if people would like to consume epel pkgs, but still > > > > want to cherry-pick which version of pkgs they need/want : what about : > > > > - creating tag/targets for epel (but not building *any* pkg there) > > > > - rsync (without any delete) epel > > > > - use "koji import" to import all epel pkgs, and also new versions when > > > > new pkgs appear > > > > > > > > That would mean : nothing to build on cbs, and people can just "cbs > > > > tag-build" existing imported pkgs. > > > > > > > > Would that work for everybody ? > > > > > > The problem is that there may be build/link issues when a new version of > > > a package gets introduced in EPEL. Already build binaries may not be > > > able to function with the updated package from EPEL, it may be required > > > to rebuild some packages in the SIG. > > > > > > For Gluster we have at least one of such a candidate (userspace-rcu). In > > > order to prevent these issues, the old userspace-rcu needs to be > > > provided by some repository too. Not sure if we should tag a build of an > > > EPEL package into a repository provided by the SIG... > > > > > > There are very few dependencies that Gluster has with EPEL. I am fine > > > with rebuilding those few packages in order to keep things simple and > > > prevent unexpected issues. > > > > > > > > I am laughing at this because one of the reasons why things like gluster > > and openstack are no longer available in EPEL was because they were moving > > too fast for users and we were getting complaints about those package > > changes being broken. And then we cause the same issue to gluster/openstack > > users because things in EPEL moved too quickly. > > I do not remember seeing EPEL moving too quickly, but it is a > possibility that needs to be accounted for. As for Gluster moving too > quickly, see Kalebs reply. > > > That said, I agree it is a problem and I am not saying people HAVE to use > > EPEL directly. I just want to make it possible that > > > > 1. You can use EPEL if you want, and not use EPEL if you want. > > This requires all the dependencies to be part of the SIG repositories. > Which is fine, but I am not sure if that was included in the original > proposal (it mentioned build-roots though). > > > 2. You can import src.rpm/spec files into CBS from EPEL as easily as > > possible. > > 3. You can get whatever fixes into EPEL so people who are doing things like > > mixing gluster and epel or openstack and epel aren't broken. > > The last point might prove to be difficult. Not all EPEL maintainers > care about features that CentOS offers (like pp64le support). Updating a > library (+SONAME bump) would require rebuilds of several packages in > EPEL. Requests like https://bugzilla.redhat.com/1410302 may get stalled > because of the extra work that is involved (+BZ 1507090). 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. The only problems come up when there's a CentOS-only architecture. EPEL has never enabled CentOS architectures that don't exist in RHEL. > 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 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. -- 真実はいつも一つ！/ Always, there's only one truth!