[CentOS-devel] What to do with SCLo SIG content that is EOL
trevor.hemsley at ntlworld.com
Fri Oct 13 11:55:29 UTC 2017
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
>> 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.
More information about the CentOS-devel