[CentOS-devel] A Big Idea for a New Decade [was: Minutes for CentOS Board of Directors 2019-12-18 Meeting]

Stephen John Smoogen

smooge at gmail.com
Tue Jan 7 17:41:14 UTC 2020

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.

More information about the CentOS-devel mailing list