CentOS 8.2 - Disable all EPEL repos?

Should the following EPEL repos be disabled for CentOS 8.2 for the latest version of Virtualmin, Webmin and Usermin?

epel-modular.repo
epel-playground.repo
epel-testing-modular.repo
epel-testing.repo
epel.repo

Thanks for the heads up.

We enable epel.repo during installation. Others may be safe(ish) to enable after installation of Virtualmin (but maybe not…testing and playground are experimental…I don’t know what modular is, but probably also experimental since it’s not documented anywhere obvious). I don’t actually have epel-modular on my test systems…not sure where it came from for you.

We recommend proceeding with extreme caution when installing packages from third party sources, or from exprimental/beta EPEL/SCL sources. If you really know what you’re doing you can probably do whatever you want…but, be aware that if you modify the packages of things Virtualmin manages, you’ll probably need to make some configuration changes (SCL, for example, installs into /opt so paths don’t match what Webmin thinks they are for services like e.g. MySQL/Mariadb or PHP).

1 Like

epel-modular.repo is the safest of the bunch and is very useful. Tread lightly with the others.

My understanding is that ‘modular’ is a yum/dnf system for avoiding clashes while staying slightly ahead of official repos. CentOS, Remi and other repos store modular packages but epel-modular is how Fedora separates theirs from everything else. Not all packages are modular but when they are there tends to be both safe and risky choices.

Recently I tampered with Nginx so I’ll use that as an example. By default CentOS 8.2 will install Nginx 1.14 unless its nginx module is reset and a newer version is enabled. Here’s a modular package in action that installs from CentOS AppStream:

dnf module reset nginx
dnf module enable nginx:1.16
dnf install nginx

The riskier option is to use dnf module enable nginx:1.18 to step up to the newest version possible from epel-testing-modular.

Another example is PHP 7.2 as the default for CentOS 8.0 and 8.1. When 8.2 was released recently PHP 7.3 became available from AppStream. But for 7.3 to replace 7.2 you first need to switch modules.

Sometimes modular packages overlap. The newest package from CentOS tends to be the oldest package from EPEL, Nginx 1.16 for example. In that case AppStream has priority.

Typing dnf module list [package-name] will give you a summary of what you’ve got and what’s available from enabled repos.

1 Like

Ok I’ll leave EPEL off unless I need to upgrade something specific. I’ll make an LVM snapshot before I update anything from EPEL just in case it breaks. Thx for the heads up.

Thanks for the explanation @ramin, though it isn’t entirely right. epel.repo doesn’t include anything that would conflict with OS-provided packages, so it is “safest” if that’s our metric.

Modular sounds like it takes the place of SCL, except maybe it doesn’t have specially built packages that have different names and different install paths. SCL packages can be installed alongside system packages, but may conflict if you try to use both simultaneously without awareness and care. Sounds like modular just gives you new packages in the regular place? That’s valuable, especially given how old packages in CentOS can be, but I wouldn’t call it “safer”.

Yeah, I knew I might be sticking my neck out but like you said, with modular packaging there isn’t much to go on documentation-wise (makes me wonder if the maintainers know how to explain it). One thing I’m certain about, third-party repos and modular install options make CentOS a lot more interesting. Thanks for the extra learning module. Every little bit helps.

Yeah, I think we’re all guessing. The docs are nearly non-existent.

So, I think I’m inclined to give it a few weeks or months before I start taking EPEL Modular seriously…it at least needs a clear explanation of what it is on the EPEL website and some docs about how long packages will be maintained, etc. We have a lot of users who “set it and forget it” and if modular requires a manual upgrade every few months to keep a maintained set of packages (i.e. from 1.8 to 1.9 or whatever of a given package), that’s just not going to be something a lot of people can or will do.

1 Like

I think it’s well understood that safety comes first in your line of work, especially while juggling different distros. For those of us who start fires with repo madness – we just have to train ourselves to be fire fighters too. But half the time I’m on the side of caution. For instance, I’d like to upgrade Redis 5 to 6 to get rid of plain text authentication once and for all. Do I wait on CentOS or get it from Remi now? I’m on the fence about it because it’s not coming from remi-safe.

This topic was automatically closed 4 days after the last reply. New replies are no longer allowed.