<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 12 Jul 2019 at 13:24, Niels de Vos <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> Just wondering : if people would like to consume epel pkgs, but still<br>
> want to cherry-pick which version of pkgs they need/want : what about :<br>
> - creating tag/targets for epel (but not building *any* pkg there)<br>
> - rsync (without any delete) epel<br>
> - use "koji import" to import all epel pkgs, and also new versions when<br>
> new pkgs appear<br>
> <br>
> That would mean : nothing to build on cbs, and people can just "cbs<br>
> tag-build" existing imported pkgs.<br>
> <br>
> Would that work for everybody ?<br>
<br>
The problem is that there may be build/link issues when a new version of<br>
a package gets introduced in EPEL. Already build binaries may not be<br>
able to function with the updated package from EPEL, it may be required<br>
to rebuild some packages in the SIG.<br>
<br>
For Gluster we have at least one of such a candidate (userspace-rcu). In<br>
order to prevent these issues, the old userspace-rcu needs to be<br>
provided by some repository too. Not sure if we should tag a build of an<br>
EPEL package into a repository provided by the SIG...<br>
<br>
There are very few dependencies that Gluster has with EPEL. I am fine<br>
with rebuilding those few packages in order to keep things simple and<br>
prevent unexpected issues.<br>
<br></blockquote><div><br></div><div>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. </div><div><br></div><div>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</div><div><br></div><div>1. You can use EPEL if you want, and not use EPEL if you want.</div><div>2. You can import src.rpm/spec files into CBS from EPEL as easily as possible.</div><div>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.</div><div><br></div><div>If those goals are useful and we can make that happen.. I will do what I can to make it happen.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Niels<br>
_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org" target="_blank">CentOS-devel@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/centos-devel" rel="noreferrer" target="_blank">https://lists.centos.org/mailman/listinfo/centos-devel</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Stephen J Smoogen.<br><br></div></div></div>