C8 has
nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64
CS8 has
nodejs-10.23.1-1.module_el8.4.0+645+9ce14ba2
should CentOS Stream 8's package version not be at least == C8?
-- Thanks Leon
On Wed, Aug 10, 2022 at 6:31 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
C8 has
nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64
CS8 has
nodejs-10.23.1-1.module_el8.4.0+645+9ce14ba2
should CentOS Stream 8's package version not be at least == C8?
The nodejs:10 Application Stream was retired in April 2021 per https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle
As CentOS Stream is the development space for the next minor release of RHEL, this ran into an awkward timing scenario. The nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64 build is from an errata after the RHEL 8.3 release, but the release of RHEL 8.4 was in May 2021 which fell after the end of support for the nodejs:10 module. Nothing was ever intended to ship in RHEL 8.4 for nodejs:10, therefore CentOS Stream 8 has no newer builds to work with.
In all cases, I would recommend migrating to a supported version of nodejs.
josh
On Wed, Aug 10, 2022 at 07:30:34AM -0400, Josh Boyer wrote:
On Wed, Aug 10, 2022 at 6:31 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
C8 has
nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64
CS8 has
nodejs-10.23.1-1.module_el8.4.0+645+9ce14ba2
should CentOS Stream 8's package version not be at least == C8?
The nodejs:10 Application Stream was retired in April 2021 per https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle
As CentOS Stream is the development space for the next minor release of RHEL, this ran into an awkward timing scenario. The nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64 build is from an errata after the RHEL 8.3 release, but the release of RHEL 8.4 was in May 2021 which fell after the end of support for the nodejs:10 module. Nothing was ever intended to ship in RHEL 8.4 for nodejs:10, therefore CentOS Stream 8 has no newer builds to work with.
In all cases, I would recommend migrating to a supported version of nodejs.
The awkward bit is that nodejs:10 is still marked as the default module in CS8, even though it's unsupported. This is not the only example since the same can be said for the redis:5 and maybe more.
Running `dnf install nodejs` on a fresh system gives you unsupported software.
On Wed, Aug 10, 2022 at 9:34 AM Ewoud Kohl van Wijngaarden ewoud+centos@kohlvanwijngaarden.nl wrote:
On Wed, Aug 10, 2022 at 07:30:34AM -0400, Josh Boyer wrote:
On Wed, Aug 10, 2022 at 6:31 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
C8 has
nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64
CS8 has
nodejs-10.23.1-1.module_el8.4.0+645+9ce14ba2
should CentOS Stream 8's package version not be at least == C8?
The nodejs:10 Application Stream was retired in April 2021 per https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle
As CentOS Stream is the development space for the next minor release of RHEL, this ran into an awkward timing scenario. The nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64 build is from an errata after the RHEL 8.3 release, but the release of RHEL 8.4 was in May 2021 which fell after the end of support for the nodejs:10 module. Nothing was ever intended to ship in RHEL 8.4 for nodejs:10, therefore CentOS Stream 8 has no newer builds to work with.
In all cases, I would recommend migrating to a supported version of nodejs.
The awkward bit is that nodejs:10 is still marked as the default module in CS8, even though it's unsupported. This is not the only example since the same can be said for the redis:5 and maybe more.
Yes, that is indeed awkward, but it is also by design. This is one of the things we learned and adjusted in RHEL 9/CentOS Stream 9.
josh
Running `dnf install nodejs` on a fresh system gives you unsupported software. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Aug 10, 2022 at 10:04 AM Josh Boyer jwboyer@redhat.com wrote:
On Wed, Aug 10, 2022 at 9:34 AM Ewoud Kohl van Wijngaarden ewoud+centos@kohlvanwijngaarden.nl wrote:
On Wed, Aug 10, 2022 at 07:30:34AM -0400, Josh Boyer wrote:
On Wed, Aug 10, 2022 at 6:31 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
C8 has
nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64
CS8 has
nodejs-10.23.1-1.module_el8.4.0+645+9ce14ba2
should CentOS Stream 8's package version not be at least == C8?
The nodejs:10 Application Stream was retired in April 2021 per https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle
As CentOS Stream is the development space for the next minor release of RHEL, this ran into an awkward timing scenario. The nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64 build is from an errata after the RHEL 8.3 release, but the release of RHEL 8.4 was in May 2021 which fell after the end of support for the nodejs:10 module. Nothing was ever intended to ship in RHEL 8.4 for nodejs:10, therefore CentOS Stream 8 has no newer builds to work with.
In all cases, I would recommend migrating to a supported version of nodejs.
The awkward bit is that nodejs:10 is still marked as the default module in CS8, even though it's unsupported. This is not the only example since the same can be said for the redis:5 and maybe more.
Yes, that is indeed awkward, but it is also by design. This is one of the things we learned and adjusted in RHEL 9/CentOS Stream 9.
Unfortunately, in the case of both nodejs and nginx, this is still a problem on CentOS Stream 9.
Personally, I would have preferred there to be no default streams for these given the lifecycle setup for it. Alas...
-- 真実はいつも一つ！/ Always, there's only one truth!
On Wed, Aug 10, 2022 at 10:42 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Aug 10, 2022 at 10:04 AM Josh Boyer jwboyer@redhat.com wrote:
On Wed, Aug 10, 2022 at 9:34 AM Ewoud Kohl van Wijngaarden ewoud+centos@kohlvanwijngaarden.nl wrote:
On Wed, Aug 10, 2022 at 07:30:34AM -0400, Josh Boyer wrote:
On Wed, Aug 10, 2022 at 6:31 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
C8 has
nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64
CS8 has
nodejs-10.23.1-1.module_el8.4.0+645+9ce14ba2
should CentOS Stream 8's package version not be at least == C8?
The nodejs:10 Application Stream was retired in April 2021 per https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle
As CentOS Stream is the development space for the next minor release of RHEL, this ran into an awkward timing scenario. The nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64 build is from an errata after the RHEL 8.3 release, but the release of RHEL 8.4 was in May 2021 which fell after the end of support for the nodejs:10 module. Nothing was ever intended to ship in RHEL 8.4 for nodejs:10, therefore CentOS Stream 8 has no newer builds to work with.
In all cases, I would recommend migrating to a supported version of nodejs.
The awkward bit is that nodejs:10 is still marked as the default module in CS8, even though it's unsupported. This is not the only example since the same can be said for the redis:5 and maybe more.
Yes, that is indeed awkward, but it is also by design. This is one of the things we learned and adjusted in RHEL 9/CentOS Stream 9.
Unfortunately, in the case of both nodejs and nginx, this is still a problem on CentOS Stream 9.
I'm not sure I follow. There are no default module streams in CentOS Stream 9.
Personally, I would have preferred there to be no default streams for these given the lifecycle setup for it. Alas...
The existence of an Application Stream with a shorter lifecycle is different than a module default stream. It is possible to simply update the version of e.g. nginx in the package to a newer version after the lifecycle for that specific version retires. 'yum install nginx' would still work and result in a supported scenario, with a different version. There are of course other implications and there are no guarantees that is the course of action anyone will take, but the problem solved was default module stream interactions. Lifecycle is separate.
josh
This should probably be branched into a separate discussion:
On Wed, Aug 10, 2022 Neal Gompa ngompa13@gmail.com wrote:
On Wed, Aug 10, 2022 Josh Boyer jwboyer@redhat.com wrote:
Yes, that is indeed awkward, but it is also by design. This is one of the things we learned and adjusted in RHEL 9/CentOS Stream 9.
Unfortunately, in the case of both nodejs and nginx, this is still a problem on CentOS Stream 9.
To expand on this, RHEL 9.10 is (if I can do math right), expected around May/June 2027. There are currently a number of Application Streams that are not supported for the full life of the product and even ending earlier than the Full Support phase in which CentOS Stream resides. These include:
https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle...
- Ansible Core - Nov 2023 - .NET 6 - Nov 2024 - OpenJDK 1.8 - May 2026 - OpenJDK 11 - Oct 2024 - MySQL 8.0 Apr 2026 - Node.js 16 - Apr 2024
.NET and the JDK's are a bit of a special case, they have their own separate life cycles: https://access.redhat.com/support/policy/updates/net-core https://access.redhat.com/articles/1299013#OpenJDK_Life_Cycle
And some might not be aware that Node.js part of the Red Hat Middleware stack: https://access.redhat.com/support/policy/updates/jboss_notes/#p_nodejs
This is probably contentious but the only "good" solution, and I use that term loosely, I can think of is software that isn't supported for the entirety of RHEL's lifespan (e.g. full life cycle/rolling) should not be installable by default. Instead they should be provided by a module that acts as an "opt-in" policy to these tools. An exception would probably be the SCLs like gcc-toolset as they are a semi-separate ecosystem. I don't believe it's a good strategy to allow users (and RHEL customers) to "yum install" unsupported software by default when they may not be aware of the life cycles. As much as I'd like to think every user is intimately familiar with our documentation/support policies, that would obviously not match reality.
However...
On Wed, Aug 10, 2022 Josh Boyer jwboyer@redhat.com wrote:
The existence of an Application Stream with a shorter lifecycle is different than a module default stream. It is possible to simply update the version of e.g. nginx in the package to a newer version after the lifecycle for that specific version retires. 'yum install nginx' would still work and result in a supported scenario, with a different version. There are of course other implications and there are no guarantees that is the course of action anyone will take, but the problem solved was default module stream interactions. Lifecycle is separate.
Is it guaranteed that all non-module non-special-case limited life cycle Application Streams will behave this way via a rebase, meta-package, provides/obsoletes, etc or is this scenario still being hashed out? I'm genuinely asking as I haven't seen this spelled out anywhere. If yes, that allays some of the concerns I mentioned above as they effectively become quasi-rolling Streams. Otherwise we're left with the same situation as RHEL 8 sans Modularity, i.e. a user running "yum install" on an unmodified system is left with unsupported software as we don't remove unsupported packages from the CDN.
As a side note, is NGINX an Application Stream? It's not listed under the RHEL 9 streams on the life cycle page.
-- Mike
On Wed, Aug 10, 2022 at 4:54 PM Mike Rochefort mroche@redhat.com wrote:
This should probably be branched into a separate discussion:
On Wed, Aug 10, 2022 Neal Gompa ngompa13@gmail.com wrote:
On Wed, Aug 10, 2022 Josh Boyer jwboyer@redhat.com wrote:
Yes, that is indeed awkward, but it is also by design. This is one of the things we learned and adjusted in RHEL 9/CentOS Stream 9.
Unfortunately, in the case of both nodejs and nginx, this is still a problem on CentOS Stream 9.
To expand on this, RHEL 9.10 is (if I can do math right), expected around May/June 2027. There are currently a number of Application Streams that are not supported for the full life of the product and even ending earlier than the Full Support phase in which CentOS Stream resides. These include:
https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle...
- Ansible Core - Nov 2023
- .NET 6 - Nov 2024
- OpenJDK 1.8 - May 2026
- OpenJDK 11 - Oct 2024
- MySQL 8.0 Apr 2026
- Node.js 16 - Apr 2024
.NET and the JDK's are a bit of a special case, they have their own separate life cycles: https://access.redhat.com/support/policy/updates/net-core https://access.redhat.com/articles/1299013#OpenJDK_Life_Cycle
And some might not be aware that Node.js part of the Red Hat Middleware stack: https://access.redhat.com/support/policy/updates/jboss_notes/#p_nodejs
This is probably contentious but the only "good" solution, and I use that term loosely, I can think of is software that isn't supported for the entirety of RHEL's lifespan (e.g. full life cycle/rolling) should not be installable by default. Instead they should be provided by a module that acts as an "opt-in" policy to these tools. An exception would probably be the SCLs like gcc-toolset as they are a semi-separate ecosystem. I don't believe it's a good strategy to allow users (and RHEL customers) to "yum install" unsupported software by default when they may not be aware of the life cycles. As much as I'd like to think every user is intimately familiar with our documentation/support policies, that would obviously not match reality.
We're starting to get off-topic a bit for the CentOS Stream list, but we can continue on.
RHEL users have other mechanisms to help them be aware of the different Application Stream lifecycles, primarily based on Insights. We have found that removing content availability is considered significantly more painful and presents a content management nightmare, so the possibility of installation remains.
For clarity, customers can download entire RHEL major releases that are no longer supported. CentOS itself still allows this as well. This is neither new, nor is it limited to Application Streams at all.
However...
On Wed, Aug 10, 2022 Josh Boyer jwboyer@redhat.com wrote:
The existence of an Application Stream with a shorter lifecycle is different than a module default stream. It is possible to simply update the version of e.g. nginx in the package to a newer version after the lifecycle for that specific version retires. 'yum install nginx' would still work and result in a supported scenario, with a different version. There are of course other implications and there are no guarantees that is the course of action anyone will take, but the problem solved was default module stream interactions. Lifecycle is separate.
Is it guaranteed that all non-module non-special-case limited life cycle Application Streams will behave this way via a rebase, meta-package, provides/obsoletes, etc or is this scenario still being hashed out? I'm genuinely asking as I haven't seen this spelled out
I explicitly said in my email there are no guarantees that method will be used at all. The example of nginx was used purely as such, an example to further conversation. You could replace it with "foo".
In terms of what will actually happen, that depends on the Application Stream and requirements for it.
anywhere. If yes, that allays some of the concerns I mentioned above as they effectively become quasi-rolling Streams. Otherwise we're left with the same situation as RHEL 8 sans Modularity, i.e. a user running "yum install" on an unmodified system is left with unsupported software as we don't remove unsupported packages from the CDN.
Understanding support lifecycles and content management is something end users have needed to be aware of for some time. Application Stream concepts introduced in RHEL 8 are a variant of that, but they aren't new. Red Hat Software Collections in RHEL 7 had the same dynamics. Thus far, folding that into a more easily accessible content set and repo structure has been received fairly positively. The notable negative feedback was default streams, which we fixed.
We continue to look at ways to help users understand and manage the complexity of software lifecycles but removing access isn't a solution.
As a side note, is NGINX an Application Stream? It's not listed under the RHEL 9 streams on the life cycle page.
Nginx is an Application Stream. We expect newer versions to appear on that page as they are made available.
josh
On Wednesday, August 10, 2022 9:04:09 AM CDT Josh Boyer wrote:
The awkward bit is that nodejs:10 is still marked as the default module in CS8, even though it's unsupported. This is not the only example since the same can be said for the redis:5 and maybe more.
Other examples: php 7.2 - May 2021 postgresql 10 - May 2024
EOL dates were taken from https://access.redhat.com/support/policy/updates/ rhel-app-streams-life-cycle . Both of these modules have full life streams which are not the default.
Yes, that is indeed awkward, but it is also by design. This is one of the things we learned and adjusted in RHEL 9/CentOS Stream 9.
Indeed, this was a pretty poor design decision. In addition to users getting unsupported software by default, it causes problems for EPEL. Due to one of the many deficiencies of modularity, we're only able to build against default modules, even if they're unsupported.
On 8/10/22 11:43, Maxwell G via CentOS-devel wrote:
On Wednesday, August 10, 2022 9:04:09 AM CDT Josh Boyer wrote:
The awkward bit is that nodejs:10 is still marked as the default module in CS8, even though it's unsupported. This is not the only example since the same can be said for the redis:5 and maybe more.
Other examples: php 7.2 - May 2021 postgresql 10 - May 2024
I will tag and push these later if they are released in 8 Linux and not 8 Stream .. I have already tagged the nodejs:10 module.
If anyone knows any other items that are newer in 8 Linux and not updated in 8 Stream, send it here.
I will need to verify these, of course, but I have permission now.
EOL dates were taken from https://access.redhat.com/support/policy/updates/ rhel-app-streams-life-cycle . Both of these modules have full life streams which are not the default.
Yes, that is indeed awkward, but it is also by design. This is one of the things we learned and adjusted in RHEL 9/CentOS Stream 9.
Indeed, this was a pretty poor design decision. In addition to users getting unsupported software by default, it causes problems for EPEL. Due to one of the many deficiencies of modularity, we're only able to build against default modules, even if they're unsupported.
Thanks, Johnny Hughes
On 8/10/22 11:58, Johnny Hughes wrote:
On 8/10/22 11:43, Maxwell G via CentOS-devel wrote:
On Wednesday, August 10, 2022 9:04:09 AM CDT Josh Boyer wrote:
The awkward bit is that nodejs:10 is still marked as the default module in CS8, even though it's unsupported. This is not the only example since the same can be said for the redis:5 and maybe more.
Other examples: php 7.2 - May 2021
That looks to be the latest php module build: https://koji.mbox.centos.org/koji/buildinfo?buildID=7751
postgresql 10 - May 2024
https://koji.mbox.centos.org/koji/buildinfo?buildID=20445
And that looks like the latest postgresql build that we have.
Neither of those look newer in 8 Linux.
<snip>
Thanks, Johnny Hughes
Aug 10, 2022 11:58:39 AM Johnny Hughes johnny@centos.org:
If anyone knows any other items that are newer in 8 Linux and not updated in 8 Stream, send it here.
I was talking about the lifecycle not whether c8s had older versions. My point is that the full lifecycle streams should have been the default ones. -- Thanks,
Maxwell G (@gotmax23) Pronouns: He/Him/His
On 8/10/22 06:30, Josh Boyer wrote:
On Wed, Aug 10, 2022 at 6:31 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
C8 has
nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64
Since this is EOL, it may not matter, but I could just publish this version in CentOS Stream 8 as well.. since it is already built and released. But people probably should not be using it anyway.
Thoughts?
CS8 has
nodejs-10.23.1-1.module_el8.4.0+645+9ce14ba2
should CentOS Stream 8's package version not be at least == C8?
The nodejs:10 Application Stream was retired in April 2021 per https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle
As CentOS Stream is the development space for the next minor release of RHEL, this ran into an awkward timing scenario. The nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64 build is from an errata after the RHEL 8.3 release, but the release of RHEL 8.4 was in May 2021 which fell after the end of support for the nodejs:10 module. Nothing was ever intended to ship in RHEL 8.4 for nodejs:10, therefore CentOS Stream 8 has no newer builds to work with.
In all cases, I would recommend migrating to a supported version of nodejs.
josh
Thanks, Johnny Hughes
Am 10.08.22 um 17:44 schrieb Johnny Hughes:
On 8/10/22 06:30, Josh Boyer wrote:
On Wed, Aug 10, 2022 at 6:31 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
C8 has
nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64
Since this is EOL, it may not matter, but I could just publish this version in CentOS Stream 8 as well.. since it is already built and released. But people probably should not be using it anyway.
Why this came up here was because a distro-sync would lead to a downgrade ...
-- Leon
On Wed, 2022-08-10 at 10:44 -0500, Johnny Hughes wrote:
On 8/10/22 06:30, Josh Boyer wrote:
On Wed, Aug 10, 2022 at 6:31 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
C8 has
nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64
Since this is EOL, it may not matter, but I could just publish this version in CentOS Stream 8 as well.. since it is already built and released. But people probably should not be using it anyway.
Thoughts?
Personally, I'd love to see it there even if it is for an EOL product. If for nothing else, it would help ensure completeness.
Pat
On 8/10/22 10:44, Johnny Hughes wrote:
On 8/10/22 06:30, Josh Boyer wrote:
On Wed, Aug 10, 2022 at 6:31 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
C8 has
nodejs-10.24.0-1.module_el8.3.0+717+fa496f1d.x86_64
Since this is EOL, it may not matter, but I could just publish this version in CentOS Stream 8 as well.. since it is already built and released. But people probably should not be using it anyway.
Thoughts?
<snip>
OK, I have tagged in the last nodejs:10 into CentOS Stream 8, it should go out on the next compose, sometime this week.
Thanks, Johnny Hughes
-
Ewoud Kohl van Wijngaarden -
Johnny Hughes -
Josh Boyer -
Leon Fauster -
Maxwell G -
Mike Rochefort -
Neal Gompa -
Patrick Riehecky