EPEL packages. Trouble ahead?

3 posts / 0 new
Topic locked
Last post
#1 Sat, 07/21/2012 - 08:55
eddieb

EPEL packages. Trouble ahead?

At some point, I enabled the EPEL repo to install a specific package but forgot to disable it afterwards. I realized I ended up with a few packages from EPEL.

yum list installed | grep epel
GeoIP.x86_64                     1.4.8-1.el6               @epel
ack.noarch                       1.96-1.el6                @epel
awstats.noarch                   7.0-2.el6                 @epel
epel-release.noarch              6-7                       installed
inotify-tools.x86_64             3.14-1.el6                @epel
libmcrypt.x86_64                 2.5.8-9.el6               @epel
mod_evasive.x86_64               1.10.1-10.el6             @epel
ncftp.x86_64                     2:3.2.4-1.el6             @epel
perl-Authen-PAM.x86_64           0.16-8.el6                @epel
perl-File-Next.noarch            1.06-2.el6                @epel
php-mcrypt.x86_64                5.3.3-1.el6               @epel
proftpd.x86_64                   1.3.3g-1.el6              @epel

Two questions:

1) I've installed yum protectbase. Is this recommended for a virtualmin server?

2) Could these packages sourced from EPEL become a problem? For example, will proftpd only update from EPEL since it came from EPEL? Do I need to do anything? I rather fix things now than run have an emergency later...

CentOS 6.3 Webmin: 1.590 Virtualmin: 3.93.gpl GPL

Thanks

Sat, 07/21/2012 - 16:19
andreychek

Howdy,

EPEL is the most compatible of the third party repos... in fact, a lot of the Virtualmin packages are based on EPEL packages. So I wouldn't be too worried about having enabled that.

That said, I also tend to recommend only pulling in packages you need from third party repos, so I might recommend not pulling in any more than already were unless you need them.

-Eric

Sun, 07/22/2012 - 10:52 (Reply to #2)
eddieb

Eric

Thank you for the clear answer, as usual!

Topic locked