EPEL Package Filtering - Am I being overcautious?

I run an Alma (and before that CentOS) shop, and historically I’ve always kept the EPEL repo disabled by default and enabled for specific package installs in the interests of avoiding unexpected package conflicts, and when I moved to Foreman for updates I maintained this procedure via the use of setting of specific include package filters for the packages I need. By and large the only packages from EPEL provided are a handful of utility tools (ncdu, iotop, nmon netc), although my boxes do use Zabbix from Zabbix’s own repo, a package which is also present in EPEL and has been known to cause problems.

However, this means that if I need to enable a package from the EPEL Repo I have to push out a whole new Content View. I was up until today using a Weekly sync plan, and depending on my position in my monthly patching cycle this was introducing the risk of additional, untested packages also being added into the Content View. I’ve partially alleviated this issue today by switching from a Weekly sync to a Monthly first Tuesday of the month Sync via cron, but it’s still a layer of additional toil enabling packages in this way.

I don’t really want to be checking every box every month for any random EPEL packages that might crop up during the upgrade cycle either (although I guess I am in the process of automating patching and could devise a check for this).

On the plus side however it would allow me to still maintain an extra layer of control against packages that are installed.

None-the-less I’m starting to suspect that this approach might be a little overcautious however, and I was wondering how other people handle EPEL packages and any potential conflicts that may or may not surface in practice? Do they crop up with any regularity in other people’s experience? Would I be better just setting one or two excludes for known troublemakers instead?


Would hammer content-view version incremental-update do what you want?

1 Like

I think you’re right to be cautious, you never know if EPEL will suddenly include a newer version of a package that your ecosystem relies on.

I would recommend incremental-update like @quartsize mentioned. If you already have EPEL as a repository in your content view version, you can copy any content from the EPEL library and generate a new “point-release” version of your content view version.

Thank you @quartsize @iballou - this does exactly what I need it to! I was aware you could perform incremental content view updates, but I was under the mistaken impression that they could only be used in conjunction with errata, not packages as well.

I will keep the majority of EPEL excluded by default and use this if any packages need to be installed outside of the normal content cycle.

For anybody who might find it helpful in future the syntax is:

$ hammer content-view version incremental-update
–content-view-version-id cv_ID
–packages pkg_name1,pkg_name2
–lifecycle-environment-ids env_ID1, env_ID2,…
–organization-id org_ID