Я делал это раньше. Это было не красиво, но это сработало, тем более что Perl продавцов обычно 2-3 года.
Я начал с создания собственного RPM-пакета perl, который устанавливал perl в другое место, например /opt/. Это было довольно просто. В основном я начал с этого, потому что не хотел, чтобы системные утилиты, использующие perl, ломались при обновлении / установке новых модулей. Мне пришлось изменить все мои скрипты, указав #!/opt/bin/perl вверху, и иногда я даже играл с путем, чтобы убедиться, что мой perl появился первым.
Затем я взял RPM с исходным кодом mod_perl и изменил его, чтобы использовать мой /opt/bin/perl вместо /usr/bin/perl. У меня нет доступа к изменениям, которые я сделал, так как это было на другом концерте. Мне потребовалось немного поиграть, чтобы получить это.
Это сработало, но я не волшебник RPM, поэтому проверка зависимостей не сработала так хорошо. Например, я мог удалить свой пользовательский RPM и сломать все. Для меня это не имело большого значения, поэтому я пошел дальше.
Я также смешивал RPM с установками модулей CPAN (я упоминал, что мы создали наше собственное зеркало CPAN с нашим собственным кодом?). Это было немного хрупким тоже. Опять же, у меня не было ресурсов (то есть времени), чтобы выяснить, как согнуть cpan2rpm , чтобы использовать мой perl и не вызывать конфликты RPM.
Если бы у меня было все это снова, я бы сделал пользовательский RPM на 5,10 об / мин и просто заменил системный perl. Затем я использовал бы cpan2rpm для создания RPM-пакетов, необходимых для моего программного обеспечения, и скомпилировал свой собственный mod_perl RPM.