<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Thu, Jul 11, 2019, at 08:38, Stephen John Smoogen wrote:<br></div><blockquote type="cite" id="qt"><div dir="ltr"><div dir="ltr"><br></div><div><br></div><div class="qt-gmail_quote"><div class="qt-gmail_attr" dir="ltr">On Thu, 11 Jul 2019 at 09:25, Pat Riehecky <<a href="mailto:riehecky@fnal.gov">riehecky@fnal.gov</a>> wrote:<br></div><blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-gmail_quote"><div><br></div><div><br></div><div>On 7/10/19 4:09 PM, Thomas Oulevey wrote:<br></div><div> > Hi Stephen,<br></div><div> ><br></div><div> > Thanks for your questions.<br></div><div> ><br></div><div> > Inline my feedback.<br></div><div> ><br></div><div> > On 10.07.19 22:57, Stephen John Smoogen wrote:<br></div><div> >><br></div><div> >> 1. What are the policies that EPEL would need to change?<br></div><div> ><br></div><div> > EPEL is shipping only latest build in their repo. We can't build <br></div><div> > against older packages. Another issue is that koji doesn't allow that <br></div><div> > either. The intermediate repo metadata only contains latest builds and <br></div><div> > it is not configurable as far as I remember.<br></div><div> ><br></div><div> >> 2. What are the parts of EPEL that are a moving target compared to <br></div><div> >> the continuous release method of CentOS?<br></div><div> ><br></div><div> > We can build packages and stick to them for a whole lifecycle of a SIG <br></div><div> > project release for both "Requires:" and "Buildrequires:".<br></div><div> ><br></div><div> > I am sure there are other concerns that can be discussed by the pkgs <br></div><div> > maintainers.<br></div><div> ><br></div><div> <br></div><div> Would it be possible to permit some SIGs to opt into EPEL if they desire?<br></div><div> <br></div><div> Or to put another way:<br></div><div> <br></div><div> The EPEL project has a Special Interest in EL packages. While this <br></div><div> isn't a CentOS SIG, it is a Group. Existing CentOS SIGs are able to opt <br></div><div> into depending on CentOS SIGs. Would permitting SIGs to opt into <br></div><div> depending on EPEL be much different?<br></div><div> <br></div></blockquote><div><br></div><div>It might require us to be a CentOS SIG also (which I don't currently see a problem with) and also have a way to make those packages available to the koji in way which doesn't break builders. [AKA some sort of local mirror which allows for keeping old copies of rpms.]<br></div><div><br></div><div> <br></div><blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-gmail_quote"><div>Pat<br></div><div> <br></div><div> -- <br></div><div> Pat Riehecky<br></div><div> <br></div><div> Fermi National Accelerator Laboratory<br></div><div> <a rel="noreferrer" href="http://www.fnal.gov">www.fnal.gov</a><br></div><div> <a rel="noreferrer" href="http://www.scientificlinux.org">www.scientificlinux.org</a><br></div><div> <br></div><div> _______________________________________________<br></div><div> CentOS-devel mailing list<br></div><div> <a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a><br></div><div> <a rel="noreferrer" href="https://lists.centos.org/mailman/listinfo/centos-devel">https://lists.centos.org/mailman/listinfo/centos-devel</a><br></div></blockquote></div><div><br></div><div><br></div><div>-- <br></div><div class="qt-gmail_signature" dir="ltr"><div dir="ltr"><div>Stephen J Smoogen.<br></div></div></div></div><div>_______________________________________________<br></div><div>CentOS-devel mailing list<br></div><div>CentOS-devel@centos.org<br></div><div>https://lists.centos.org/mailman/listinfo/centos-devel<br></div><div><br></div></blockquote><div><br></div><div>To me this isn't a "building" question, this is a "delivery" question. Currently the guidance is for the SIGs to own their dependency chain, and to ship their deliverables depending on things that are self-contained (or self-contained to CentOS-built content at least).<br></div><div><br></div><div>Currently there is a lot of EPEL rebuild activity going on to support the SIGs, and I think this is where we can make some improvements with the converged git structure. We, in general, want to make it easier to take things from Fedora/EPEL branches and convert them into CentOS branches, and that workflow would make the process of consuming EPEL packages (even with a rebuild) a lot less painful. <br></div><div><br></div><div>--Brian<br></div></body></html>