<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 14 May 2019 at 07:57, Jan Staněk <<a href="mailto:jstanek@redhat.com">jstanek@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">As the person in charge of maintaining updates for the rh-* SCLs,<br>
I can say that I'm not shipping/caring about these once they are marked<br>
as EOL; so from my POV, they can be removed if it is not desirable to<br>
have them in the repositories.<br>
<br>
That being said, there is a possibility that a inter-SCL dependency will<br>
break, as have happened last summer with rh-ror42 (maintained at the<br>
time) and rh-nodejs4 (EOL). Since upstream does not remove the<br>
unmaintained packages from the repos, such dependencies won't be<br>
discovered until someone does remove them.<br>
<br>
Basically, I'm in favor of removing the EOL SCLs, but it might break<br>
non-EOL collections, which will take some time to fix.<br></blockquote><div><br></div><div>Is there a way to archive these versus remove them? That way people who are looking for them would know that they are EOL but they could make their own copy and maintain it themselves?</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">
-- <br>
Jan Staněk<br>
Associate Software Engineer, Core Services<br>
Red Hat Czech<br>
<a href="mailto:jstanek@redhat.com" target="_blank">jstanek@redhat.com</a>     IM: jstanek<br>
<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>