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:
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:
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:
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
On Wed, Aug 10, 2022 at 10:04 AM Josh Boyer jwboyer@redhat.com wrote:
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:
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:
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:
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:
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.
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.
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:
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:
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.
Thanks, Johnny Hughes
On 8/10/22 11:58, Johnny Hughes wrote:
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
-
Ewoud Kohl van Wijngaarden -
Johnny Hughes -
Josh Boyer -
Leon Fauster -
Maxwell G -
Mike Rochefort -
Neal Gompa -
Patrick Riehecky