perl 5.18 в CentOS 6.5 установил. Результат ценный?

Есть Red Hat Software Collections, там, правда, perl-5.16, но главная идея — это устанавливать новые версии под своим именем, например, perl516-perl-5.16.3-12.el6.i686.rpm, чтобы в системе оставался старый perl-5.10.

ИМХО, заменять системный perl с 5.10 на 5.18 не нужно, так как можно получить не работающие системные скрипты, причём майнтенеры дистрибутива это фиксить не будут.

Вот это и есть настоящая свобода. Спасибо за замечание. Каждый шаг имеет и хорошие и дурные последствия. Пакеты, которые мне нужно было собрать, были настроены на использование системного perl 5.18, поэтому устанавливать его в отдельном окружении - это изменять параметры сборки и работы этих приложений (я пока не в силах). Мой выбор очевиден из моих возможностей - что умею то и творю. Это уже, кста, несвобода. Меня только успокаивает в статье (ссылка в п2 списка 1) утверждение, что все версии perl разрабатываются с учетом обратной совместимости и системные скрипты с малой вероятностью будут страдать в выполнении от смены системного perl-a. Вот их безопасность могла бы пострадать от вызовов новых версий функций с тем же именем в логике алгоритмов обратной совместимости.

Да, если скрипты начинаются с:

#!/usr/bin/perl

#!/usr/bin/env perl

Возможно, что когда-нибудь SCL доработаю и в /usr/bin/perl будет хитрый wrapper, который в зависимости от имени скрипта и т.д. будет вызывать нужную версию perl'а.

системные скрипты с малой вероятностью будут страдать в выполнении от смены системного perl-a.

Я не знаю, насколько много различий между 5.10 и 5.18, но вы можете далеко не сразу обнаружить проблему, что где-то в системе что-то стало работать не так, как раньше. Если 5.18 был нужен только какому-то отдельному скрипту, то я бы создал отдельное chroot-окружение для этого скрипта и туда бы ставил 5.18.