On Wed, Apr 2, 2014 at 12:52 AM, C. L. Martinez <carlopmart at gmail.com> wrote: >> >> Pretty much everyone needs EPEL for something - so it is not enough to >> not break anything in CentOS base, but you also need to not >> break/conflict with/replace anything in EPEL. So really, the best >> approach would just be to add any missing modules to EPEL. >> > > Thanks Les, but EPEL here it is not an option. I need a lot of perl > modules that it doesn't exists in EPEL repos. Yes, I can use some (a > few) of perl modules published in EPEL, but they are outdated ... And > it is another problem .. My real point is that you probably do (or will) need some EPEL modules, And unless you are very careful to make RPMs with the same names and higher version numbers for all of your non-base/EPEL modules, it will be very likely that updates or future installs of packaged applications will pull in those older, incompatible modules as dependencies, breaking whatever else you might have installed. So, while it is easy to make something work with a mix of packages and CPAN, they aren't likely to keep working for the life of your system unless you either keep them separate with different paths/library paths that you manage for the non-stock version or careful package naming and numbering to make sure your versions satisfy dependencies and aren't clobbered in updates. And the latter approach can also cause trouble with applications that expect older versions, although perl programmers are normally pretty good about maintaining backwards compatibility. -- Les Mikesell lesmikesell at gmail.com