On Wed, Aug 10, 2022 at 4:54 PM Mike Rochefort <mroche at redhat.com> wrote: > > 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. 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 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 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