CPAN против APT: конфликты в версиях?
Я нигде не могу найти ответ на этот вопрос: конфликтует ли модуль, установленный через APT, с модулем, установленным через CPAN?
Наряду с этим возникает вопрос: где живут установленные модули CPAN? Доступны ли они глобально или только пользователю, устанавливающему программу? Откуда ты знаешь, какой? Как вы узнаете, что установлено и что имеет приоритет?
Следует ли вообще использовать CPAN при установке модулей через APT?
4 ответа
На 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...