On Wed, Apr 2, 2014 at 12:52 AM, C. L. Martinez <carlopmart@xxxxxxxxx> 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@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
