[CentOS-devel] Community build services and EPEL8

[Niels de Vos]

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).

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.

> If those goals are useful and we can make that happen.. I will do what I
> can to make it happen.

Yes they are! Thanks for thinking about this problem and possible
solutions,
Niels