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?
Honza
----- Original Message -----
From: "Honza Horak" hhorak@redhat.com To: "The CentOS developers mailing list." centos-devel@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)?
Pavel
Honza
On 13/10/17 12:49, Pavel Valena wrote:
----- Original Message -----
From: "Honza Horak" hhorak@redhat.com To: "The CentOS developers mailing list." centos-devel@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.
Trevor
On 13/10/17 12:55, Trevor Hemsley wrote:
On 13/10/17 12:49, Pavel Valena wrote:
----- Original Message -----
From: "Honza Horak" hhorak@redhat.com To: "The CentOS developers mailing list." centos-devel@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
On 10/12/2017 01:23 PM, Honza Horak wrote:
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?
The way we currently handle SIG content right now, it is placed in the main CentOS (and soon to be altarch) tree at:
centos/7/<sig_name>/<$arch>/<sub_repo>/
the /7/ is basically always the latest point release. So it was 7.3.1611 and it is now 7.4.1708.
Right now, the movement of things to vault happens after a point release. So the 7.3.1611 tree will move to vault (both altarch/ and centos/ branches) sometime after the point release. Usually a couple weeks, but the 32 bit Intel kernel and grub2 made it take some time and the removal of the 7.3.1611 tree will happen this weekend.
I think the easiest process for SIGs would be this (If we are going to continue to do 7.3.1611 and 7.4.1708 repos, etc.):
We currently have to copy SIG content from old release (7.3.1611) to the new release (7.4.1708). That is the perfect time to NOT move things you want to EOL. They will stay in the 7.3.1611 tree and only the things you want to support would move to the 7.4.1708 tree.
If you currently look in vault, under 7.1.1503, 7.2.1511 or 7.3.1611 .. for example :
http://vault.centos.org/7.1.1503/storage/x86_64/
http://vault.centos.org/7.2.1511/storage/x86_64/
So, in the 7.1.1503 dir .. that is the storage things that were in 7.1.1503 at the end of the release .. the day that RHEL 7.2 got released. All those dirs were copied over as is to our 7.2.1511 release. If we wanted to EOL (just as an example) gluster-3.6/ , then we could just not copy it over to 7.2.1511 at all. It would then only appear in vault in the 7.1.1503 dir .. which is where you want people to get it if they need it (since we did not copy it to 7.2.1511 when we released that). You could then release a new centos-release-gluster36 file that changes the repo to
http://vault.centos.org/7.1.1511/storage/x86_64/gluster-3.6/
People who choose to try and run gluster-3.6 would need to grab that RPM and use that repo. Everyone one else needs to upgrade.
We currently produce, in our CentOS-Release RPM, a repo file called CentOS-Vault.repo.
If you look at that repo, you will see that it provides all the Base, Updates, Extras, etc. etc. repos for all old versions and they are turned off by default.
Anyway .. that is how it works now. If we need a different process .. where, for example all the SIGs are in their own spot, so a live and a vault area for each repo and we link those into releases. So, our live 7.4.1708 would link into the live SIG area .. and all the trees on vault for centos don't contain SIG content at all, it lives in it's own vault area not tied directly to 7.0.1406, or 7.1.1511, or 7.2.1611 .. etc.
I think the easiest thing would be to leave them tied to specific releases (because that is what it was built against, and you will not have rebased libraries issues, like a new nss or openssl from a newer release). So I think the easiest thing is just to take out the older SIG content at point release time.
Thanks, Johnny Hughes
-
Honza Horak -
Johnny Hughes -
Pavel Valena -
Trevor Hemsley