On Tue, 7 Jan 2020 at 11:46, Matthew Miller <mattdm at mattdm.org> wrote: > > On Tue, Jan 07, 2020 at 11:22:59AM -0500, Stephen John Smoogen wrote: > > > 6. For the love of all that is pink and fluffy, we need to update the > > > versions of third party packages we ship. If RHEL won't, CentOS should. > > > For instance, we still ship Jetty 9.2, which is EOL and not receiving > > > security updates. 9.3 is also EOL. 9.4 is quite stable at this point (as > > > they are about to go beta on 10.0), so we should be shipping 9.4. > [...] > > The true purpose of an enterprise software is to make sure that a site > > can run crufty old software which depends on some version of a library > > no longer supported by upstream beyond simple bug fixes. [I can say > > from experience that updating jetty will break all kinds of commercial > > payroll apps which expect X version]. In the end, enterprise software > > What about providing an updated Jetty as an optional module in EPEL? I see > we have 9.4.24 in Fedora. This seems like a pretty good example of what I'm > saying about fast and slow streams -- we actually _have_ this in our > ecosystem already, just not in a consumable way. If it were in EPEL, RHEL or > CentOS users who want to strap a nitro-burning sidecar on their semi truck > for their use case could do so. >From my experience with jetty in the past on enterprise systems you find out that you need to run 2-3 versions on the same system at the same time. All of them want to be called jetty and they all want a bunch of environment variables set up that are 'unique' to that version. This is where SCL's are a better fit. For Gregory's problem, modularity does look like a better fix for 8 BUT the person writing the module needs to know a bunch of things: 1. How to make a module. [This seems to be about ~20 people.] 2. What software depends on jetty which will need to be modularized also. This isn't software dep but API deps. [That will be the packagers of java applications and such.] 3. Know how to avoid setting up a libgit2 and similar problems that Fedora has run into. We do not want someone to install EPEL-8 modularity and find out that we smoked their production system on the first yum update or some similar thing because a module replaced something it needed but was required for some other thing (OR vice versa). From the conversations in FESCO about this.. htis is still reliant on human knowledge and detection versus a test framework. However it doesn't fix it for 7 which is probably where the lion share of people using Gregory's software that needs a newer jetty are. > -- > Matthew Miller > <mattdm at fedoraproject.org> > Fedora Project Leader > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel -- Stephen J Smoogen.