Будет ли обновление Perl ломать старую версию в Linux?

Question

Я обновляю perl с perl58 до perl588 в Suse Linux. Похоже, что несмотря на то, что Config.pm существует для более старой версии, установка более новой версии ломает старую версию. Хотя обновление Perl на других ОС, таких как HP и AIX, выполняется. Не беспокоить старую версию. Например: версии perl58 и perl588 находятся в папке, например, "/ usr / standard_perl":

/usr/standard_perl/perl58 (directory)
/usr/standard_perl/perl588 (directory)

и имеют символические ссылки, указывающие на него.

До и после обновления ссылки:

До:

perl58_link -> /usr/standard_perl/perl58

После того, как:

perl5_link ->   /usr/standard_perl/perl588 
perl58_link ->  /usr/standard_perl/perl588
perl588_link -> /usr/standard_perl/perl588

Теперь, когда я пытаюсь запустить простую команду "./perl -V" из / usr / standard_perl / perl58 / bin, старая версия жалуется на то, что Config.pm не найден, хотя он очень хорошо присутствует в своей собственной древовидной структуре.

Возможно ли, что в Linux perl следует жестко закодированному пути для @ INC. Такое поведение наблюдается только в Linux.

Меня беспокоит, что я не могу перейти к работе, поскольку есть сценарии, которые выполнялись для более старой версии, и если такое поведение существует, мне нужно знать, возможно ли это исправить, или это известное поведение Linux.

Я не уверен, могло ли это быть, потому что теперь старые ссылки после обновления указываются на более новую версию, и просто ссылки недостаточно, и нужно изменить что-то еще в LINUX?

Примечание: 1. Perl модули отдельно поддерживаются для каждой версии 2. Я не смешиваю файлы с предыдущей версией. 3. Мы хотим, чтобы все старые сценарии Perl, работающие на производственных серверах, не ломались и вместо этого использовали последнюю версию для поддержки версий Perl. 3a.Здесь нужно настроить ссылки, указывающие на последнюю версию, вместо их собственных версий.

Замечание: Только на Linux видят такое поведение. Стоит отметить один момент, когда я добавляю ссылки старой версии на последнюю версию. @INC автоматически обновляется до последней версии INC, а не в LINUX.

Я что-то здесь упускаю?

Answer 1

Я никогда не видел этой проблемы в Linux. Я оставляю исходный perl в его расположении (/ usr / bin / perl) и просто компилирую свой собственный perl для установки в / usr / local / bin (или что-то еще), и никогда не видел поломок старой версии.

Вы не говорите

• как вы получили / usr / standard_perl / perl588 (скомпилированный, заданный в формате rpm или что-то в этом роде, предварительно скомпилированный tarball, ...)
• какие опции вы использовали при настройке компиляции

Вы также очень расплывчаты со своими данными - perl58_link, standard_perl и т. Д. - где это на самом деле? В большинстве случаев это не имеет значения, но иногда это имеет значение.

Если переместить ссылку назад, все начинает работать? Если вы переместите все дерево 5.8.8 куда-нибудь еще, все начнет работать? Можете ли вы восстановить свой базовый Perl из RPM или чего-то еще, чтобы попытаться заставить его работать? IMO, базовый Perl работает первостепенно, вторичный Perl всегда бонус. (Я бы взял то же мнение о других базовых инструментах Unix, таких как shell, awk, sed или даже python, или о том, что ваш дистрибутив использует для управления пакетами. Менее для неосновных инструментов, таких как Java, но если бы я запускал приложения Java в производстве, то я бы сказал то же самое и здесь.)

Answer 2

Оставьте систему perl исполняемой в одиночку, скомпилируйте свою собственную, и ваши Perl-программы будут запускаться с использованием той, которую вы скомпилировали

Все системные программы, написанные на Perl, должны начинаться с:

#! /usr/bin/perl

Все несистемные программы на Perl, пользовательские программы:

Этот будет использовать тот, который когда-либо исполняемый Perl найден первым на $PATH. (аналогично 'which perl')

#! /usr/bin/env perl

Другой вариант - указать, где именно тот исполняемый файл, который вы хотите использовать:

#! /opt/bin/perl

#! /opt/perl/bin/perl

#! /opt/perl/5.10.0/bin/perl

#! /opt/perl-5.10.0/bin/perl

#! /home/$user/perl/bin/perl

#! ~/bin/perl

Или каков путь к исполняемому файлу perl.

Answer 3

Никогда не заменяйте /usr/bin/perl на тот, который вы скомпилировали сами!

Я сделал это однажды в Ubuntu 7.10, и это сломало мою систему. Я мог войти в систему и сделать почти все, но не смог, например, изменить внешний вид. В итоге я запустил «sudo nano $filename» на каждой программе Perl на моем компьютере и изменил их так, чтобы они работали под Perl 5.10 вместо Perl 5.8.

После чего мне пришлось установить Ubuntu 8.10 с нуля, когда он наконец вышел.

Вы также можете столкнуться с несовместимостью, если вы используете cpan или cpanp для установки модулей, поскольку они могут иметь несовместимое изменение функции. А для двоичного совместимого исполняемого файла perl необходимо переустановить все модули, для которых требуется XSubs.

Именно поэтому все программы на Perl, которые я пишу, добавляют заголовок '#!/usr/bin/env perl' и добавляем путь к исполняемому файлу Perl, в начало переменной $PATH.