<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 11, 2019 at 1:39 PM Stephen John Smoogen <<a href="mailto:smooge@gmail.com">smooge@gmail.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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 11 Jul 2019 at 05:16, Alfredo Moralejo Alonso <<a href="mailto:amoralej@redhat.com" target="_blank">amoralej@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"><div dir="ltr"><div dir="ltr"><br></div><div>Hi,<br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 10, 2019 at 10:53 PM Thomas Oulevey <<a href="mailto:thomas.oulevey@cern.ch" target="_blank">thomas.oulevey@cern.ch</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">Hello folks,<br>
<br>
In the planning of next Community build services, a new question came up.<br>
<br>
In the past we never allowed EPEL repositories to be used as external <br>
repositories for SIGs. Doing so, would allow to build against EPEL <br>
packages and not duplicate the work for maintainers in EPEL/SIGs.<br>
<br>
However it would mean also building against a moving target which can be <br>
difficult if EPEL policies are the same as today.<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As EPEL 8 is also in the making it would be good to hear what SIGs think <br>
about this specific issue.<br>
<br></blockquote><div><br></div><div>In CloudSIG we currently are explicit about not supporting enabling EPEL
 repos to deploy OpenStack. We are rebuilding the required deps in the 
SIG repo when needed. The main reasons for this is that we want to stay 
with specific versions of dependencies for stable releases and not 
following latest builds in EPEL on every supported release. Also, 
rebuilding them in CBS allows us to test any update before pushing it to
 the actual repos.</div><div></div></div></div></blockquote><div><br></div><div>Those are valid reasons for doing that. There is a side effect that people seem to want both and then our two groups are each blamed for breaking each other. But that is mostly people not reading the directions and aiming a loaded gun at their foot.</div><div><br></div><div>Do you use any other SIG work or is it a 'we rebuild everything we need and don't rely on others'? Also would it help you to rebuild or push back fixes if the source code you used for that was shared?</div><div><br></div></div></div></blockquote><div><br></div><div>We face different scenarios:</div><div><br></div><div>- For content provided by other SIGs as Ceph (StorageSIG), qemu/kvm (VirtSIG) or some monitoring (OpsTools), we consume them directly from the SIG repos for the version we want to use.</div><div>- In some (few) cases, there are specific libraries or packages that we need and have been built in other SIGs or by CentOS infra. In those cases we tag them in CloudSIG tags and include in our repos.<br></div><div>- For dependencies which are not in other SIGs, we rebuild them in CBS using Fedora specs (typically using epel, rawhide or recent branches). In some cases, if we need fixes that could be useful in Fedora/EPEL we try to push them. Note that in some cases we need specific changes to rebuild in CBS, i.e. removing python3 subpackages, etc...<br></div><div><br></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"><div dir="ltr"><div class="gmail_quote"><div></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"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Let us know !<br>
<br></blockquote><div><br></div><div>Best regards,</div><div><br></div><div>Alfredo<br></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">
-- <br>
Thomas Oulevey<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></div>
_______________________________________________<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-m_-4006603370566587848gmail_signature"><div dir="ltr">Stephen J Smoogen.<br><br></div></div></div>
_______________________________________________<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></div>