I mean that the EOL date is past - see https://access.redhat.com/support/policy/updates/rhscl - sometimes by as much as 3 years. That means those packages are unmaintained and dangerous.  I reckon there are more than 5000 packages there that fall under this.

yum --disablerepo=* --enablerepo=centos-sclo-rh,centos-sclo-sclo devtoolset-3* devtoolset-4* devtoolset-6* git19* mariadb-5.5* maven30* mogodb24* mysql55* nginx16* nodejs010* perl516* php54* php55* postgresql92* python33* rh-git29* rh-mariadb100* rh-mongodb26* rh-mongodb30upg* rh-mysql56* rh-nginx18* rh-nodejs4* rh-passenger40* rh-perl520* rh-postgresql94* rh-python34* rh-ror41* rh-ruby22* rh-thermostat16* rh-varnish4* ror40* ruby193* ruby200* rust-toolset-7* sclo-python34* thermostat1* v8314* rh-mariadb101* rh-maven33* rh-mongodb32* rh-nodejs6* rh-postgresql95* rh-python35* rh-ror42* rh-ruby23* sclo-python35* sclo-ror42* rh-eclipse46* sclo-cassandra3* sclo-git212* sclo-git25* go-toolset* libasan* libcilkrts* liblsan* libmpx* libtsan* libubsab* llvm-toolset-7* sclo-subversion19* sclo-vagrant1* | wc -l 5361

Yes, that has some blank lines in there and maybe some other stuff inflating that count but it still ends up with 5000 unmaintained and EOL packages.

We should not be making these publicly available. It only encourages people to use them!

Trevor

On 13/05/2019 22:11, Nico Kadel-Garcia wrote:

By “dead”, do you mean the upstream RHEL channel is entirely disabled? Or just unmaintained?

Sent from my iPhone

...

On May 13, 2019, at 2:47 PM, Trevor Hemsley via CentOS-devel centos-devel@centos.org wrote:

Hi all

I just had a glance at the various repos installed by centos-release-scl on CentOS 7 and a large number of the packages available in the CentOS version of this repo are both old and out of date and more importantly, EOL. They should be removed from our repos ASAP.

I know we had/have a policy of cleaning these repos up at point release times but it's quite apparent that we have missed all of these for a number of point releases from 7.3 onwards. Thus I propose we make an exception for these and remove them anyway, regardless of point release time or not. A lot of them should have been gone for 3 years already.

The following are all dead as per https://access.redhat.com/support/policy/updates/rhscl - some of them deader than others.

devtoolset-3 - Oct 2016 devtoolset-4 - Nov 2017 devtoolset-6 - Nov 2018 git19 - Oct 2016 mariadb-5.5 - Oct 2016 maven30 - Oct 2016 mogodb24 - Oct 2016 mysql55 - Oct 2016 nginx16 - Oct 2016 nodejs010 - Oct 2016 perl516 - Oct 2016 php54 - Oct 2016 php55 - Oct 2016 postgresql92 - Oct 2016 python33 - Oct 2016 rh-git29 - Nov 2018 rh-mariadb100 - Apr 2018 rh-mongodb26 - Apr 2018 rh-mongodb30upg - Apr 2018 rh-mysql56 - Apr 2018 rh-nginx18 - Nov 2018 rh-nodejs4 - May 2018 rh-passenger40 - Apr 2018 rh-perl520 - Apr 2018 rh-postgresql94 - Apr 2018 rh-python34 - Apr 2018 rh-ror41 - Apr 2018 rh-ruby22 - Apr 2018 rh-thermostat16 - Oct 2016 rh-varnish4 - Nov 2018 ror40 - Oct 2016 ruby193 - Oct 2016 ruby200 - Oct 2016 rust-toolset-7 - ??? sclo-python34 - Apr 2018 thermostat1 - Oct 2016 v8314 - Apr 2018

The following go EOL this month:

rh-mariadb101 - May 2019 rh-maven33 - May 2019 rh-mongodb32 - May 2019 rh-nodejs6 - May 2019 rh-postgresql95 - May 2019 rh-python35 - May 2019 rh-ror42 - May 2019 rh-ruby23 - May 2019 sclo-python35 - May 2019 sclo-ror42 - May 2019

These are not mentioned on the above page but could be part of other SCLs that are still current (maybe!)

rh-eclipse46* sclo-cassandra3 - ???? sclo-git212 - ??? sclo-git25 - ??? go-toolset - no expiration date given libasan[2,3,4,5] libcilkrts, liblsan, libmpx, libtsan, libubsab[1] - ???? llvm-toolset-7 - part of devtoolset-7? sclo-subversion19 - ??? sclo-vagrant1 - ???

Trevor

---

CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

On Tue, May 14, 2019 at 08:05:33AM +0200, Fabian Arrotin wrote:

On 13/05/2019 20:47, Trevor Hemsley via CentOS-devel wrote:

...

Hi all

I just had a glance at the various repos installed by centos-release-scl on CentOS 7 and a large number of the packages available in the CentOS version of this repo are both old and out of date and more importantly, EOL. They should be removed from our repos ASAP.

I know we had/have a policy of cleaning these repos up at point release times but it's quite apparent that we have missed all of these for a number of point releases from 7.3 onwards. Thus I propose we make an exception for these and remove them anyway, regardless of point release time or not. A lot of them should have been gone for 3 years already.

The following are all dead as per https://access.redhat.com/support/policy/updates/rhscl - some of them deader than others.

<snip>

Thanks a lot for the list Trevor,

+1

Although I agree that devtoolset-n n<=6 are no longer supported (no bug fix/obsolete) I would rather keep them as some user might have built software stacks (HPC people?) on those and they "need" to keep them running.

For public facing software framework, nginx/redis/php/... +1

Cheers

Tru

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.

Am 14.05.2019 um 14:40 schrieb Stephen John Smoogen smooge@gmail.com:

On Tue, 14 May 2019 at 07:57, Jan Staněk jstanek@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?

In the past such stuff was moved to vault.centos.org. The reason to do this at point releases?

-- LF

On Tue, May 14, 2019 at 11:37 AM Trevor Hemsley via CentOS-devel centos-devel@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@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.

On Tue, May 14, 2019 at 12:00 PM John R. Dennison jrd@gerdesas.com wrote:

On Tue, May 14, 2019 at 11:46:45AM -0400, Nico Kadel-Garcia wrote:

...

That repository is for is source, not binaries. Pulling things *out*

I presume, then that you didn't actually look at the contents? I see _many_, _many_ binary rpms.

I was looking at a higher level in vault.centos.org. You're right.

OK, that addresses my legacy access concerns, and there is a "repodata" there to support yum access as needed. Yeah, I'd be on board with migrating the obsolete components to that repo.

On Tue, May 14, 2019 at 12:12:09PM -0400, Nico Kadel-Garcia wrote:

OK, that addresses my legacy access concerns, and there is a "repodata" there to support yum access as needed. Yeah, I'd be on board with migrating the obsolete components to that repo.

Awesome. Now that the project has your approval it can proceed, this is great news!

John

On Tue, May 14, 2019 at 5:26 PM Phil Perry pperry@elrepo.org wrote:

On 14/05/2019 17:55, John R. Dennison wrote:

...

On Tue, May 14, 2019 at 12:12:09PM -0400, Nico Kadel-Garcia wrote:

...

OK, that addresses my legacy access concerns, and there is a "repodata" there to support yum access as needed. Yeah, I'd be on board with migrating the obsolete components to that repo.

Awesome. Now that the project has your approval it can proceed, this is great news!

John,

I had hoped that the days of these kind of facetious comments in open source communities were well and truly behind us and that we had entered an era where we could all demonstrate respect towards each other and contribute in a positive and constructive manner. Please, let us not return to the ways of the past.

I'd merely taken that as slightly exasperated mocking that I'd taken so long to convince, not as a personal denigration.

John, I'd meant "Yeah, I'd be on board" as a friendly acknowledgement that this would address my legacy software access concerns, not a claim that it needs my personal approval.

Now, with all that in mind: Should there be some kind of comment. Should there be some kind of acknowledgement in the CentOS-Vault repo along with a pointer to such a repository of "these are so dangerously obsolete that we've overridden RHEL's publication of the original sclo channel and decided to shut these elsewhere"? What would such a channel be called? Would its contents be left permanently in the "obsolete" channel?

Nico Kadel-Garcia wrote:

On Tue, May 14, 2019 at 3:17 AM Tru Huynh tru@centos.org wrote:

...

On Tue, May 14, 2019 at 08:05:33AM +0200, Fabian Arrotin wrote:

...

On 13/05/2019 20:47, Trevor Hemsley via CentOS-devel wrote:

...

Hi all

I just had a glance at the various repos installed by

centos-release-scl

...

...

on CentOS 7 and a large number of the packages available in the

CentOS

...

...

version of this repo are both old and out of date and more

importantly,

...

...

EOL. They should be removed from our repos ASAP.

I know we had/have a policy of cleaning these repos up at point

release

...

...

times but it's quite apparent that we have missed all of these for a number of point releases from 7.3 onwards. Thus I propose we make an exception for these and remove them anyway, regardless of point

release

...

...

time or not. A lot of them should have been gone for 3 years

already.

...

...

The following are all dead as per https://access.redhat.com/support/policy/updates/rhscl - some of

them

...

...

deader than others.

<snip>

Thanks a lot for the list Trevor,

+1

Although I agree that devtoolset-n n<=6 are no longer supported (no bug fix/obsolete) I would rather keep them as some user might have built software stacks (HPC people?) on those and they "need" to keep them running.

For public facing software framework, nginx/redis/php/... +1

Cheers

Tru

I've done things like that. And picking and choosing which obsolete parts to clear out is awkward. If they're still in the RHEL channels upstream, I'd encourage keeping them, even if those components are obsolete and deprecated. I've certainly seen people running versions of MySQL, for example, that are extremely obsolete because they couldn't choose a migration technique. And the tendency of EPEL to discard all but the current versions has been the bane of my "we need to keep the binaries and sources available" existence. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

Agreed. There have been several times I've been burned when "yum history undo last" failed because epel had removed the most recent previous version. Keep up the good work!

c