Alternative to modules?

Posted Oct 25, 2024 15:10 UTC (Fri) by zdzichu (subscriber, #17118)
In reply to: Alternative to modules? by dsommers
Parent article: Kadlčík: Copr Modularity, the End of an Era

I saw modularity as a workaround for RHEL shipping old software – a way to install newer packages in isolated way. This was shoehorned into Fedora where it never made sense. Fedora is about shipping latest software.

This doesn't mean you need to port your software to the newest versions constantly. First, each Fedora release is supported for over one year. Second, there are legacy packages available. For example, at this moment on my F41 system: `nodejs` is at version 22.8, but there are packages for `node18` and `node20`, too.

Python is at 3.13 and nginx at 1.26.2, no alternate versions available, but I believe compatibility story is much better for them than for nodejs.

So the ”alternative“ is to use latest runtime, update for each other version or use compat packages.

Alternative to modules?

Posted Oct 25, 2024 15:54 UTC (Fri) by barryascott (subscriber, #80640) [Link] (2 responses)

> Python is at 3.13 and nginx at 1.26.2, no alternate versions available,

You can install many of python versions side by side in fedora, I think python3.6 through to python3.14 (shortly).
Try `dnf install python3.10` as an example.

Alternative to modules?

Posted Oct 25, 2024 16:21 UTC (Fri) by dsommers (subscriber, #55274) [Link]

Some of these can indeed be installed in parallel on Fedora. But running Fedora is in some situations not applicable, as the platform stability RHEL provides is superior to Fedora - and you don't need to update to the latest release at least every year.

Fedora does not have the same stability guarantees RHEL provides. And that's where the dnf modules in RHEL was very handy: The BaseOS packages has a long term stability guarantee while the modules itself can have a shorter life time - which for most of the modules alone is fine.

I can also agree that modules in Fedora is not necessarily a good match. But for LTS/Enterprise distributions it's a very different story.

Alternative to modules?

Posted Oct 27, 2024 21:55 UTC (Sun) by jafd (subscriber, #129642) [Link]

But you cannot build system packages against any other python than the one provided by /usr/bin/python. Which in the case of modularity (what if that software you need also needs some python tooling, but it needs to run against a specific version of python which is not what the system ships with?) becomes an increasingly harder problem. Also, if you need several modules, you may suddenly run into conflicts in case said tooling is present in all/some of them, all needing a different Python version...

Alternative to modules?

Posted Oct 25, 2024 17:37 UTC (Fri) by intelfx (guest, #130118) [Link] (2 responses)

> This was shoehorned into Fedora where it never made sense. Fedora is about shipping latest software.

The quote in the article says that modularity is also going to be dropped from RHEL, so the GP’s concern is still valid, or am I missing something here?

Alternative to modules?

Posted Oct 27, 2024 19:53 UTC (Sun) by smoogen (subscriber, #97) [Link] (1 responses)

I think that in the end, the alternative to modules is going to be home-grown containers. They are easier to build yourself the way you want them. Where they dont' work, then it will be up to sites to compile/build/deploy software in the old fashion methods of making their own RPMs or tar balls or /nfs-cluster/bin .

The problems with modularity come down to the fact that they never got a community of people who wanted to work on the code which builds and maintains them. Things like rpm, mock, and a couple of other tools have people outside of Red Hat who will patch, fix, and deploy their own versions of the systems to fix and build things themselves. Things like SCL's and modularity never got a large enough group of people who were interested in the nuts and bolts to keep something going.

Alternative to modules?

Posted Oct 30, 2024 13:46 UTC (Wed) by raven667 (subscriber, #5198) [Link]

> Things like SCL's and modularity never got a large enough group of people who were interested in the nuts and bolts to keep something going.

As someone who has used SCL I wonder if the need for it has an ebb and flow as a popular RHEL release ages and various language ecosystems deprecate old releases which are still shipped by RHEL, that this was a problem acutely felt by RHEL7 users as python3.6 support was deprecated from upstream projects requiring use of python3.9, and the same with PHP, Redis and other runtime/services, but now that (most) people have upgraded to RHEL8/9 they are new enough to be broadly compatible with upstream projects again, but in 5 or so years if there are major compatibility breaks then the desire for an SCL-like system will come back.

Maybe it's another way of saying that the replacement cycle of hardware/baseOS doesn't seem to be evenly distributed across time, there is a certain synchronicity which may have organically developed across orgs (like a rogue wave), and the desire for SCL/modularity may come back if hardware is kept in service longer.