Нигде не могу найти ответ на этот вопрос: конфликтует ли модуль, установленный через APT, с модулем, установленным через CPAN?
Наряду с этим вопросом есть и такие: Где находятся установленные модули CPAN? Доступны ли они глобально или только для устанавливающего пользователя? Как узнать, какой из них? Как узнать, что установлено и что имеет приоритет?
Стоит ли вообще использовать CPAN, если модули устанавливаются через APT?
решение1
В 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
решение2
я используюperlbrew. Он устанавливает локальную версию Perl и cpan. Все, что он делает, делается в вашем домашнем каталоге. Он прост в установке и использовании, и вы можете установить последнюю версию Perl.
решение3
При установке напрямую с CPAN я бы рекомендовал использовать local::lib в каталоге, который является вашим личным. См. технику boostrappinghttps://metacpan.org/module/local::lib
Таким образом, установленный CPAN-модуль будет использоваться только вашим пользователем и будет иметь четкое разделение с модулями, установленными с помощью APT.
Это также позволит легко избавиться от установленных CPAN-модулей, если у вас возникнут какие-либо проблемы или при обновлении Ubuntu.
Именно так я и использую его в Ubuntu.
решение4
Вы можете использовать оба, но они будут конфликтовать. Они написаны в одном месте, так что если вы установите что-то из apt, а затем установите более позднюю версию из cpan, вы можете все испортить.
Я не очень хорошо работаю с Perl, но в Python у меня определенно есть дилемма, о которой вы говорите: apt-vs-PyPI. Лично я выбираю apt, когда могу. Это значит, что я должен получать обновления, не беспокоясь о поддержке каждого отдельного пакета Python. И не только это, но это значит, что все мои системы должны работать на одной и той же версии этих пакетов.
Не всегда получается. Иногда в репозиториях нет достаточно новых вещей или что-то, что вам нужно, просто не упаковано. Ни один из способов не идеален, но я считаю, что это возможноболееИдеально. Просто осознавай, что делаешь, и все будет в порядке.
Редактировать- Чуть не забыл, есть лучший способ разбить все на разделы, чтобы система могла иметь свою собственную среду, и все, что вы разрабатываете, могло бы существовать в своей собственной среде (которой вы полностью управляете с помощью CPAN), как в Python virtualenv...