This should probably be branched into a separate discussion: On Wed, Aug 10, 2022 Neal Gompa <ngompa13 at gmail.com> wrote: > On Wed, Aug 10, 2022 Josh Boyer <jwboyer at 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#rhel9_application_streams - 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 at 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