CPAN против APT: конфликты в версиях?

Я нигде не могу найти ответ на этот вопрос: конфликтует ли модуль, установленный через APT, с модулем, установленным через CPAN?

Наряду с этим возникает вопрос: где живут установленные модули CPAN? Доступны ли они глобально или только пользователю, устанавливающему программу? Откуда ты знаешь, какой? Как вы узнаете, что установлено и что имеет приоритет?

Следует ли вообще использовать CPAN при установке модулей через APT?

В Debian и Ubuntu CPAN ( /usr/bin/cpanутилита) устанавливает модули /usr/local/lib/по умолчанию. И пакеты Debian хранят свои файлы в /usr/share/perl5/и /usr/lib/perl5/. Таким образом, файлы, установленные через /usr/bin/cpan, не будут перезаписывать файлы, установленные через apt.

Нет ничего плохого в использовании системного Perl, и смешивание кода apt и cpan, как правило, будет работать.

Вы также можете вручную упаковать любой дистрибутив cpan, недоступный в ваших репозиториях apt. Это легко с помощью инструмента dh-make-perl:

dh-make-perl --cpan Some::Module && cd Some-Module* && sudo debi

Я использую perlbrew . Он устанавливает локальную версию Perl и cpan. Все, что он делает, делается в вашем домашнем каталоге. Это просто для установки и использования, и вы можете установить последнюю версию Perl.

При установке непосредственно из CPAN я бы рекомендовал использовать local :: lib для частного каталога. Смотрите технику бустрапинга https://metacpan.org/module/local::lib

Таким образом, установленный модуль CPAN будет использоваться только вашим пользователем, и он будет очень четко отделен от модулей, установленных с помощью APT.

Это также позволит легко избавиться от установленных на CPAN модулей, если вы столкнетесь с какой-либо проблемой или при обновлении Ubuntu.

Вот как я использую это в Ubuntu.

Вы можете использовать оба, но они будут конфликтовать. Они пишутся в одно и то же место, поэтому, если вы устанавливаете что-то из apt, а затем устанавливаете более позднюю версию из cpan, вы можете все перепутать.

Я не делаю много Perl, но в Python у меня определенно есть дилемма, о которой вы говорите: apt-vs-PyPI. Я лично выбираю подходящее время, когда могу. Это означает, что я должен получать обновления без необходимости поддерживать каждый отдельный пакет Python. Не только это, но это означает, что все мои системы должны работать на одной и той же версии этих пакетов.

Это не всегда получается. Иногда у вас недостаточно новых вещей в репозиториях или что-то, что вам нужно, просто не упаковано. Ни один из способов не идеален, но я считаю, что он может быть более совершенным. Просто знайте, что вы делаете, и все должно быть в порядке.

Изменить - Почти забыл, есть лучший способ разбить вещи на части, чтобы система могла иметь свою собственную среду, и все, что вы разрабатываете, может жить в своей собственной среде (которой вы полностью управляете с помощью CPAN), как в Python virtualenv...

/programming/1423879/how-can-i-install-specialized-environments-for-different-perl-applications