0

There is a lot of fear, uncertainty and doubt when it comes to using CentOS third party repositories. Here is a section from the Repositories page for CentOS regarding the EPEL specifically:

Extra Packages for Enterprise Linux (EPEL) - (See http://fedoraproject.org/wiki/EPEL) provides rebuilds of Fedora packages for EL6 and EL7. Packages should not replace base, although there have been issues around point releases in the past. You can install EPEL by running yum --enablerepo=extras install epel-release. The epel-release package is included in the CentOS Extras repository that is enabled by default. Support available on Freenode in #epel, on mailing lists, and its issue tracker. If you are willing to help test EPEL updates before they are pushed to stable, you can enable the epel-testing repository on your development/testing servers. Enabling epel-testing on production systems is not a good idea.

I have empathized the phrase "should not". It's almost like the CentOS documentation is saying "things should be OK if you use the EPEL- but who knows, something really bad could happen too, especially around point releases".

Here is the preceding section from the Repositories page for CentOS that sums up the problem and makes three suggestions about how that problem might be solved:

NOTE: If you are considering using a 3rd Party Repository, then you should seriously consider how to prevent unintended 'updates' from these side archives from over-writing some core part of CentOS. One approach is to only enable these archives from time to time, and generally leave them disabled. See: man yum

Another approach is to use the exclude= and includepkgs= options on a per sub-archive basis, in the matching .conf file found in /etc/yum.repos.d/ See: man yum.conf

The yum Priorities plug-in can prevent a 3rd party repository from replacing base packages, or prevent base/updates from replacing a 3rd party package.

The first suggestion is essentially to disable the EPEL and other third party repositories and then use something like this to install packages:

[user@hostname ~]$ sudo dnf --enablerepo=epel install p7zip

Does the above guarantee that some core part of CentOS will not be overwritten (the documentation vaguely implies that the problem is related to updates and not necessarily installing packages)? If so, does that even help? What happens when you need to update the packages from third party repositories?

The second suggestion is to "use the exclude= and includepkgs= options on a per sub-archive basis, in the matching .conf file found in /etc/yum.repos.d/". How do I know which packages should be excluded or included and when? Is this suggestion saying I should carefully study a third party repository before installing packages from it? I'm not opposed to learning the ins and outs of yum and dnf, but it would be terribly useful to map out a basic useful strategy for new users to get their feet wet with this approach.

The third suggestion is to use the Priorities plugin, which as I understand is actually built into DNF on CentOS 8. At the bottom of the Priorities page there is this very troubling disclaimer:

Note: The upstream maintainer of yum, Seth Vidal, had the following to say about 'yum priorities' in September 2009:

Gosh, I hope people do not set up yum priorities. There are so many things about priorities that make me cringe all over. It could just be that it reminds me of apt 'pinning' and that makes me want to hurl.

This particular page from a thread called "[CentOS] What's wrong with yum-priorities?" piles on my concerns:

R P Herrold wrote:
> 'priorities' falls over and dies at that point from
> self-induced dependency hell, and CentOS is blamed for it in
> the back splatter. I was the wiki article editor who
> initially added that caveat section, after seeing priorities
> being pushed as the 'best' alternative.
>
> It is not. It is more like Russian roulette without peeking
> at the state of the chamber, for your installation. The
> mentioned 'exclude' and 'includepkg' approach is more correct,
> but also requires reading the yum and rpm man pages, and
> gaining some understanding of dependencies.

And a crystal ball to anticipate uncoordinated future changes by different parties in a single namespace and file tree. The only ways this can be solved is to either have a single repository where nothing is excluded by policy and names and files are coordinated, or to delegate out package and file namespace to repositories that can't coordinate to keep them from conflicting. Neither of these seem very likely to happen.

--
Les Mikesell

Is a "crystal ball" really necessary or is this just fear-mongering? How can I guarantee that no core part of CentOS is overwritten by third party repositories and still enjoy the packages that these repositories (particularly the EPEL) provide? How do I safely install and update packages from third party repositories? Is it at least obvious when a core part of CentOS is overwritten?

  • The first quote you posted says that epel-testing repository is not suitable for production. It does not say that for epel. I do not remember having problems from epel packages. If you are afraid disable epel on production setup. Then install updates on test setup, and when you are sure you have tested it, install that updates on production. – nobody Jan 07 '20 at 07:26
  • @nobody Is there a way to simulate core parts of CentOS being overwritten? That's the sort of thing I would like to know how to do – Harold Fischer Jan 07 '20 at 07:35
  • What are core parts? For system stability you need stable kernel and some base libraries. It depends what you run on your system. When I have to use epel repository it is usually for software, which is not available in core repositories. It is unlikely that it will overwrite core of the system. There is a possibility to update some core SW from epel, because core does not update (e.g. PHP5 -> PHP7 on CentOS 7). You have to be careful and test before going into production. Use rpm -ql <package> to see what files are in, or rpm -Va to see if important files are being changed. – nobody Jan 07 '20 at 08:34
  • Related questions are https://unix.stackexchange.com/q/463072/5132 and https://unix.stackexchange.com/q/460525/5132 . – JdeBP Jan 07 '20 at 13:49

0 Answers0