[CentOS-devel] What to do with SCLo SIG content that is EOL

[Trevor Hemsley]

On 13/10/17 12:55, Trevor Hemsley wrote:
> On 13/10/17 12:49, Pavel Valena wrote:
>> ----- Original Message -----
>>> From: "Honza Horak" <hhorak at redhat.com>
>>> To: "The CentOS developers mailing list." <centos-devel at centos.org>
>>> Sent: Thursday, October 12, 2017 8:23:29 PM
>>> Subject: [CentOS-devel] What to do with SCLo SIG content that is EOL
>>>
>>> We discussed this on last SCLo SIG sync-up meeting -- unlike packages
>>> from CentOS base, SCL packages are not moving to Vault repos at this
>>> point, although some of them are already EOL and not getting any
>>> updates. A question was raised whether such packages should be moved to
>>> Vault.
>>>
>>> Comparing to CentOS base packages, SCL is different in packages naming
>>> -- version of the stack is part of the package name. That means, that
>>> once e.g. devtoolset-3 got EOL, yum won't update them ever, even though
>>> there are some newer versions available (those use different name though)..
>>>
>>> Moving such packages from mirrors to Vault would basically mean some
>>> setups will get broken for users.
>>>
>>> It's understandable, that some users are still fine using EOL packages,
>>> but they would need to change repos to the Vault url.
>>>
>>> What do you think -- should we start moving EOL SCLs into Vault? How big
>>> problem would that be for you?
>> Do I understand it correctly that it'll be impossible to install the package in case it's moved to Vault? Isn't that actually what we want?
>>
>> Random thought: what about using Obsoletes (for EOL only)?
> I think it should be the same process used for EOL CentOS releases.
> Content should be moved to vault and made as difficult to get to as
> possible while still allowing it to be accessed if really needed.
>
> We shouldn't facilitate easy use of EOL and possibly insecure software
> packages.  Ideally that move should be done when the SCL goes EOL not
> waiting for the next point release of the CentOS version it goes along
> with. That could mean a whole year (7.2 -> 7.3 was exactly a year) where
> potentially insecure software was available for easy installation. Or in
> a worse case, if it was for CentOS 6, will we ever see a 6.10 in which
> case waiting for the next point release will never happen.

Some numbers to go with this so we can see the scope of the problem.

I went through the list on
https://wiki.centos.org/SpecialInterestGroup/SCLo/CollectionsList and
used yum list on each of the collections that are listed as "EOL
since..." (mostly 2016) and got a list of the packages that belong in
EOL collections. Stripping out the yum headings etc from that list
leaves me with a file containing 1740 lines. There are some packages
listed by yum that are too long and thus spill the version/repo name
onto the next line so that isn't quite 1740 packages but it must be
around the 1700 mark. From yum repolist, that shows me there are
5899+444 = 6343 packages in the 2 SCL repos so over 25% of packages in
those 2 repos are currently unsupported and EOL.

That's an awful lot of unsupported software that's currently too easy to
install.

Trevor