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. I'm not sure if this is really centos-devel material, it might be more appropriate in an EPEL discussion list. That said, I've worked with clients whose need for stability far exceeded EPEL's need to provide leading edge tools. This includes clients unwilling to use the python36 tools, even though they were *much* easier to use than RHEL and CentOS supported SCLO tools. > > 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). Yeah. The overlapping components of identical names is a booby trap waiting to start biting us, hard, even though it's precisely what we're seeing with RHEL 8 and the overlap of components in the highavailability, resilientstorage, and realtime software channels. The lack of a canonical repository for each package becomes.... awkward. > 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. It's an old and tricky problem. If possible, I'd encourage using a distinct naming scheme for packages outside the EPEL repository, to distinguish them. It can be mitigated with "Provides:" and perhaps "Conflicts" statements. This is what IUS does, at https://ius.io/ . I've worked with them to provide updates for tools like the latest git release in the RHEL and CentOS environments. EPEL used this with python36 and python34, effectively. I suggest that it would be OK to do this for the various sigs and have alternative package names from EPEL. Frankly, I wish EPEL would do this now for "ansible", which is now in RHEL channels and causes real contortions if EPEL i senabled on a RHEL host with ansible channels enabled. Nico Kadel-Garcia