[CentOS-devel] SCL packages in CentOS 7 that are expired and EOL

Nico Kadel-Garcia

nkadel at gmail.com
Tue May 14 15:46:45 UTC 2019


On Tue, May 14, 2019 at 11:37 AM Trevor Hemsley via CentOS-devel
<centos-devel at centos.org> wrote:
>
> On 14/05/2019 13:40, Stephen John Smoogen wrote:
>
>
>
> On Tue, 14 May 2019 at 07:57, Jan Staněk <jstanek at redhat.com> wrote:
>>
>> As the person in charge of maintaining updates for the rh-* SCLs,
>> I can say that I'm not shipping/caring about these once they are marked
>> as EOL; so from my POV, they can be removed if it is not desirable to
>> have them in the repositories.
>>
>> That being said, there is a possibility that a inter-SCL dependency will
>> break, as have happened last summer with rh-ror42 (maintained at the
>> time) and rh-nodejs4 (EOL). Since upstream does not remove the
>> unmaintained packages from the repos, such dependencies won't be
>> discovered until someone does remove them.
>>
>> Basically, I'm in favor of removing the EOL SCLs, but it might break
>> non-EOL collections, which will take some time to fix.
>
>
> 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?
>
>
> Standard practice in the past has been to move expired things to vault.centos.org - for example http://vault.centos.org/centos/7.5.1804/sclo/x86_64/sclo/

That repository is for is source, not binaries. Pulling things *out*
of either binary or source repositories is a dangerous practice. It
would save space on the mirrors, but it can leave active, used RPM's
very difficult for the clients using them to recover even for analysis
and comparison to the newer versions.



More information about the CentOS-devel mailing list