Меню Рубрики

Установка perl модулей yum

Linux и Windows: помощь админам и пользователям

Администрируем и настраиваем Windows, Linux.

Как устанавливать модули Perl вручную и используя CPAN

Установка модулей для Perl требуется для работы различных утилит, применяемх в повседневной рутине администрирования. Установка Perl модулей вручную с удоволетворением всех зависимостей это довольно скучный и нудный процесс.

Установка Perl модулей с испоьльзованием CPAN намного более лучшее решение, так как все зависимости определятся и установятся автоматически. В это статье я опишу оба метода установки модулей.

Когда какой-либо нужный модуль не установлен, приложение которое его использует будет показывать следующую ошибку. В данном случае отсутствует модуль XML:arser.

Установка Perl модулей вручную

Перейдите на веб-сайт CPAN Search и найдите модуль который вам нужно скачать. В этом пример мы скачаем и установим модуль XML:arser Perl. Я скачаю XML-Parser-2.36.tar.gz в /home/download

Собираем модуль

Устанавливаем модуль

Это простой модуль без зависимостей, поэтому он установился без проблем. Обычно, любой модуль Perl имеет несколько зависимостей. Ставить все модули поочередно описанным выше методом скучнейшая задача. Я рекомендую использовать для установки CPAN метод, описанный ниже. Вручную стоит собирать модули в случае отсутсвия подключения к интернету.

Автоматическая установка Perl модулей с использованием CPAN

Проверяем установлен ли CPAN

Для установки Perl модулей используя CPAN, убедитесь что команда cpan работает. В этом примере, модуль CPAN ещё не установлен.

Установка модуля CPAN с помощью yum

Настраиваем span

При первом вызове cpan вы должны указать некоторые конфигурационные параметры как показано ниже. Я покажу только важные параметры конфигурации. Значения по умолчанию принимаются нажатием клавиши enter.

Установка Perl модулей с использованием CPAN

Вы можете использовать один из указанных тут методов для установки новых модулей:

В результате выполнения команды вы увидите

В примере выше Email::Reply зависит от нескольких других модулей. CPAN автоматически определил зависимости и установил Email::Reply и все другие необходимые модули.

Постовой

При работе с компанией ООО «Город» вывоз мусора перестанет быть для вас головной болью.

источник

Конфигурирование и подгрузка модулей Perl в Linux

Данную заметку меня побудили написать определённые сложности при выполнении одиночного скрипта на языке Perl. Казалось бы, интерпретатор языка уже установлен – бери и пользуйся. Да не тут то было. Хочу избавить других от грабель, по которым я ходил целый вечер.

Начну с того, что Perl построен по модульной архитектуре и для тех или иных целей эти модули должны быть подгружены и сконфигурированы. В интернете вроде бы полно рекомендаций как это сделать, но почему-то упускается самое важное – необходимость компиляции и линковки, поскольку установка модулей Perl – это, зачастую, сборка из исходников.

На серверах же в их минималистичных вариантах ничего подобного не установлено, поэтому, пользуясь многочисленными «готовыми» интернет-решениями, можно долго ругаться от того, что на экран вываливается масса текстовой диагностики, но в результате ничего по этим рецептам не устанавливается и мы получаем в конце концов FAIL. Так поначалу было и в моём случае.

Требовалось запустить скрипт, который обращался к библиотеке модулей LPW, да ещё и работал по SSL. При попытке запуска я получил сообщение о невозможности определить местоположение модуля UserAgent.pm, который нужен для работы с WWW и который спокойно себе лежал по указанным в переменной @INC перловым путям. С этих странностей, собственно, всё и началось. Пришлось изрядно попотеть, чтобы разобраться в том, как подгружать и настраивать модули Perl.

Итак, отталкиваясь от того, что Perl-у для установки своих модулей нужны cc, make и иже с ними, сделаем предварительную подготовку системы, чтобы всё прошло гладко. Установим необходимые пакеты для компиляции из исходников и подгрузим библиотеки для сборки программ с поддержкой SSL:

#apt-get install make gcc libssl-dev #для дистрибутивов на базе Debian
#yum install make gcc openssl-dev #для дистрибутивов на базе Red-Hat

Теперь обновим установочный менеджер самого Perl. Он называется cpan.

С ним можно работать как в интерактивном режиме, так и в режиме однострочных команд.

Запуском команды cpan мы перейдём в интерактивный режим и позволим менеджеру сконфигурировать рабочее окружение Perl в автоматическом режиме, отвечая на все приглашения «yes». По завершении обновим сам менеджер:

#cpan install CPAN
#cpan reload cpan

Вот теперь можно приступать к установке необходимых библиотек модулей.

#cpan> install LWP
#cpan> install Bundle::LWP
#cpan> install HTTP::Protocol::https

Все исходные коды устанавливаемых вами модулей скачиваются из репозитория CPAN (www.cpan.org), помещаются в каталог /root/.cpan/build/ и представлены в виде папок с названиями этих пакетов, например, LWP-Protocol-https-6.06-0, где последняя цифра, своего рода, номер неудачной попытки сборки модуля. Сколько раз вы попытаетесь его собрать, столько и будет создано однотипных папок с практически одинаковым содержимым.

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

Само собой, лучше, чтобы все тесты были пройдены, однако это не всегда критично и можно собрать модуль самостоятельно, минуя тестирование. Для этого следует перейти в соответствующую папку пакета /root/.cpan/build/package-X и поочерёдно выполнить команды:

#perl Makefile.PL
#make
#make install

Вероятность успешной сборки и загрузки модуля в боевой режим очень велика, хотя при работе целых фреймворков на Perl могут появиться жалобы на неудовлетворённые зависимости и т.п.

После завершения сборки Perl сам раскидает результат по правильным путям независимо от того, как и откуда выполнялась сборка (можно самостоятельно скачать исходники с www.cpan.org и запустить сборку из любой папки), поэтому, в принципе, папку /root/.cpan/ можно удалить, а занимает она порой немало места (в моём случае 87 Мб).

Вот, собственно, и всё, что я хотел сказать.

источник

🐧 Как установить Perl-модули на Linux

В этом кратком руководстве мы покажем, как установить модули Perl в Linux из репозитория CPAN (Comprehensive Perl Archive Network).

На момент написания данного руководства в CPAN было доступно 185128 модулей Perl.

Многие программы, написанные на языке программирования Perl, зависят от определенных модулей Perl для выполнения конкретной задачи.

Например, на днях я тестировал Sysadmin-util, который предоставляет набор полезных инструментов для системных администраторов Linux / Unix:

Когда я тестировал определенный инструмент под названием multi-ping, я столкнулся со следующей ошибкой:

Установим модули Perl на Linux

Существует множество инструментов для установки и модулей Perl.

Мы собираемся попробовать два инструмента, а именно cpan и cpanm.

Читайте также:  Установка и настройка tftp server

Стоит отметить, что для многих модулей на CPAN требуется последняя версия Perl 5.8 или выше.

Убедитесь, что вы установили пакет «make» в свой дистрибутив Linux.

«Make» — важный инструмент для создания Perl-модулей.

Если вы не устанавливаете «make», вы можете столкнуться с ошибкой, подобной приведенной ниже:

Пакет make доступен в репозиториях по умолчанию в большинстве дистрибутивов Linux.

Чтобы установить «make» в Arch Linux и его вариантах, запустите:

На Debian, Ubuntu, Linux Mint:

На RHEL, CentOS:

На SUSE/openSUSE:

Установим модули Perl, используя cpan

cpan является клиентом командной строки для репозитория CPAN и по умолчанию распространяется со всеми версиями Perl.

Чтобы установить модуль Perl, например Net :: DNS, введите в оболочку cpan команду:

После установки модуля введите «exit», чтобы вернуться в свою оболочку.

Вы также можете напрямую установить модуль из Терминала с помощью команды:

Установим модули Perl, используя Cpanminus

Cpanminus или cpanm — это клиент cpan для получения, распаковки, сборки и установки модулей из репозитория CPAN.

Это автономный скрипт без зависимостей, который требует нулевой настройки.

Многие опытные разработчики Perl предпочитают cpanm нежели cpan.

Cpanminus может быть установлен разными способами.

1. Используя Perl:

Чтобы установить последнюю версию cpanm в вашей системе Linux, просто запустите:

2. Используя менеджер пакетов дистрибутива:

cpanm также доступен в репозиториях по умолчанию нескольких дистрибутивов Linux.

Это стабильная версия, но немного старая.

Чтобы установить cpanminus на Arch Linux и его вариантах, запустите:

На Debian, Ubuntu, Linux Mint:

3. Ручная установка:

Кроме того, вы можете вручную загрузить последний двоичный файл cpanm и поместить его в ваш $PATH, как показано ниже.

Пример вывода:

Установим отсутствующие модули Perl с помощью менеджера пакетов дистрибутива

Многие модули Perl доступны в виде пакетов, поэтому вы можете установить их с помощью диспетчера пакетов вашего дистрибутива.

Чтобы найти отсутствующий модуль в Arch Linux, запустите:

Список установленных модулей Perl

Чтобы просмотреть список установленных модулей Perl, используйте команду «perldoc»:

Вы увидите следующий вывод:

В командной строке введите «l» для просмотра списка модулей.

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

Там может быть много модулей, установленных вручную или предварительно установленных с вашим дистрибутивом Linux.

Чтобы найти все установленные модули Perl, запустите:

Удалим модули Perl

Модули Perl могут быть легко удалены с помощью cpanm с помощью команды:

источник

Какой самый простой способ установить отсутствующий модуль Perl?

Есть ли более простой способ установить его, чем загружать, распаковывать, создавать и т.д.

23 ответа

обычно вы запускаете cpan в своей оболочке:

Если вы используете ActivePerl для Windows, PPM (Perl Package Manager) имеет ту же функциональность, что и CPAN.pm.

# ppm
ppm> search net-smtp
ppm> install Net-SMTP-Multipart

Многие дистрибутивы отправляют много модулей perl как пакеты.

Вы всегда должны отдавать предпочтение им при использовании автоматического (безопасности) обновлений и простоты удаления. Это может быть довольно сложно с самим инструментом cpan.

Для Gentoo есть хороший инструмент под названием g-cpan, который строит/устанавливает модуль из CPAN и создает Пакет Gentoo (ebuild) для вас.

Это здорово для того, чтобы просто установить материал. Он не обеспечивает ни одной из более сложных функций CPAN или CPANPLUS, поэтому он прост в использовании, если вы знаете, какой модуль вы хотите установить. Если у вас еще нет cpanminus, просто введите:

Также возможно установить его без использования cpan. Основная процедура начальной загрузки —

Для получения дополнительной информации перейдите на страницу App:: cpanminus и посмотрите раздел об установке.

Я отмечаю, что некоторые люди предлагают один запуск cpan под sudo. Это было необходимо для установки в системный каталог, но современные версии оболочки CPAN позволяют настроить его для использования sudo только для установки. Это намного безопаснее, так как это означает, что тесты не выполняются с правами root.

Если у вас есть старая оболочка CPAN, просто установите новый cpan ( «install CPAN» ), и когда вы перезагрузите оболочку, вам будет предложено настроить эти новые директивы.

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

Кроме того, я настоятельно рекомендую, чтобы пользователи Windows исследовали клубничный Perl. Это версия Perl, которая поставляется в комплекте с предварительно сконфигурированной оболочкой CPAN, а также с компилятором. Он также включает в себя некоторые трудно компилируемые модули Perl с их внешними зависимостями библиотеки C, в частности XML:: Parser. Это означает, что вы можете сделать то же самое, что и каждый другой пользователь Perl, когда дело доходит до установки модулей, а вещи, как правило, «работают» намного чаще.

Если вы используете Ubuntu и хотите установить предварительно упакованный модуль perl (например, geo:: ipfree), попробуйте следующее:

Несколько человек упомянули утилиту cpan, но это больше, чем просто запуск оболочки. Просто дайте ему модули, которые вы хотите установить, и пусть это сработает.

источник

Установка модулей CPAN в домашний каталог (Perl)

Материал из DiPHOST.Ru wiki system

CPAN (Comprehensive Perl Archive Network — архив Perl) — является центральным хранилищем всего, что касается Perl. В нём содержится полный дистрибутив Perl, документация и огромная коллекция библиотек (модулей). Если что-то написано на Perl, приносит пользу и бесплатно, то, вероятно, оно имеется в CPAN.

Один из способов посмотреть модули CPAN — посетить сайт http://search.cpan.org.

Содержание

Настройка консоли для работы с локальными модулями

Для того, чтобы интерпретатор Perl, вызванный из консоли, «видел» установленные локально библиотеки, добавьте в файл .profile следующие строки:

Это следует сделать ДО установки модулей, во избежании накладок при установке. Не забудьте «перелогиниться» после добавления, чтобы настройки применились.

Ручная установка

Модули находящиеся на CPAN можно скачивать и компилировать вручную. Как правило последовательность команд компиляции и требуемые модули, перечислены в файле README, обычно входящем в состав дистрибутива модуля. Все модули CPAN могут устанавливаться одним из способов: ExtUtils::MakeMaker и/или Module::Build. ExtUtils::MakeMaker использует файл Makefile.PL. Для установки в домашний каталог требуется указать переменную окружения INSTALL_BASE:

Module::Build использует файл Build.PL. Для установки в домашний каталог требуется указать ключ —install_base:

Остальные ключи и предпочтительный способ установки обычно описаны в файлах README и INSTALL внутри дистрибутива модуля.

Установка с помощью модуля CPAN

Также в состав дистрибутива Perl входит модуль под названием CPAN. Он позволяет автоматизировать операции установки необходимых модулей, включая установку зависимостей. Модуль может работать в ручном и пакетном режиме. Рассмотрим для простоты ручной режим работы. Для интерактивной работы с модулем следует набрать команду:

Читайте также:  Установка прошивки на леново р780

При первом запуске программа попытается создать конфигурационный файл и будет задавать вопросы. Проблема в том, что при любых ответах итоговый конфигурационный файл, создаваемый обычно в директории .cpan/CPAN/MyConfig.pm в домашнем каталоге, не готов к использованию для установки модулей локально. В нём нас интересуют нижеследующие строки, которые должны быть заполнены подобным образом:

Вместо $ENV <'HOME'>может стоят полный путь до домашнего каталога пользователя, например: /home/ ваш_логин

Убедившись в правильности конфигурации, можно устанавливать модули. Команда

запускает специальную интерактивную оболочку. Установка модулей в ней производится например такой командой:

Ключевое слово force позволит избежать отказа от установки в случае отрицательных результатов тестов, которые по разным причинам действительно могут быть отрицательными.

Настройка веб-сервера apache для работы с локальными модулями

В файл .htaccess в корневом каталоге сайта или в том каталоге, где будут cgi-скрипты, добавить строку:

Использование в cron

Для того, чтобы скрипты, запускающиеся по cron могли иметь доступ к локально установленным библиотекам, в начале crontab-файла следует прописать нужные строки:

Обращаем внимание, что переменные типа $PATH не разбираются в crontab и требуется полностью прописывать все пути.

источник

What’s the easiest way to install a missing Perl module?

Is there an easier way to install it than downloading, untarring, making, etc?

24 Answers 24

usually you start cpan in your shell:

If you’re using ActivePerl on Windows, the PPM (Perl Package Manager) has much of the same functionality as CPAN.pm.

# ppm
ppm> search net-smtp
ppm> install Net-SMTP-Multipart

see How do I install Perl modules? in the CPAN FAQ

Many distributions ship a lot of perl modules as packages.

  • Debian/Ubuntu: apt-cache search ‘perl$’
  • Arch Linux: pacman -Ss ‘^perl-‘
  • Gentoo: category dev-perl

You should always prefer them as you benefit from automatic (security) updates and the ease of removal. This can be pretty tricky with the cpan tool itself.

For Gentoo there’s a nice tool called g-cpan which builds/installs the module from CPAN and creates a Gentoo package (ebuild) for you.

It’s great for just getting stuff installed. It provides none of the more complex functionality of CPAN or CPANPLUS, so it’s easy to use, provided you know which module you want to install. If you haven’t already got cpanminus, just type:

It is also possible to install it without using cpan at all. The basic bootstrap procedure is,

For more information go to the App::cpanminus page and look at the section on installation.

I note some folks suggesting one run cpan under sudo. That used to be necessary to install into the system directory, but modern versions of the CPAN shell allow you to configure it to use sudo just for installing. This is much safer, since it means that tests don’t run as root.

If you have an old CPAN shell, simply install the new cpan («install CPAN») and when you reload the shell, it should prompt you to configure these new directives.

Nowadays, when I’m on a system with an old CPAN, the first thing I do is update the shell and set it up to do this so I can do most of my cpan work as a normal user.

Also, I’d strongly suggest that Windows users investigate strawberry Perl. This is a version of Perl that comes packaged with a pre-configured CPAN shell as well as a compiler. It also includes some hard-to-compile Perl modules with their external C library dependencies, notably XML::Parser. This means that you can do the same thing as every other Perl user when it comes to installing modules, and things tend to «just work» a lot more often.

источник

Установка Perl-модулей в Gentoo

Самый большой недостаток экосистемы языка Perl — управление модулями (другой кандидат на эту роль — долгострой Perl6, но не будем о нём). Что любопытно, самое большое достоинство этой же экосистемы — наличие единого архива модулей CPAN. Поразительно, собрать и организовать модули смогли, а реализовать удобную установку/обновление/удаление — нет.

Богатство выбора… или очередное TIMTOWTDI

Существует множество альтернативных подходов к этой задаче (и их количество тоже косвенно указывает на то, что ни один из них не решает проблему достаточно хорошо): cpan, cpanplus, cpanminus, pip, cpansite, minicpan/mcpani, perlbrew, cpan-outdated, cpan-listchanges, local::lib, …

Итак, у нас может быть:

  • Несколько версий самого perl (разумеется, каждая со своими глобальными модулями), в т.ч. установленные в домашний каталог юзера (см. perlbrew).
  • Глобальные (доступные при запуске perl) и локальные (подключаемые из любого каталога/каталогов, обычно располагающиеся внутри отдельного проекта или в домашнем каталоге пользователя) модули.
  • Глобальные модули бывают трёх типов: core (идущие вместе с perl), site (устанавливаемые вручную админом) и vendor (устанавливаемые менеджером пакетов вашей ОС).
  • Все глобальные модули находятся в подкаталогах «номер.версии.perl/», и эти каталоги никто автоматически не чистит. А при установке новой версии perl создаются новые аналогичные каталоги. И perl подгружает модули из каталогов всех доступных предыдущих версий. Так что умножьте core+site+vendor на количество обновлений perl — вот в таком количестве каталогов/вариантов находятся ваши глобальные модули.
  • Источники модулей тоже бывают разные: CPAN, локальные зеркала-оверлеи CPAN с приватными модулями, просто свои или скачанные из инета модули отсутствующие в CPAN-совместимой системе.

И всю эту радость надо администрировать: устанавливать, обновлять, … В Gentoo для упрощения администрирования глобальных Perl-модулей есть утилитка g-cpan, вот о ней я и хочу немного рассказать.

Рабочая среда

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

  1. Речь не идёт об установке своих модулей на хостинги, мы работаем с целым сервером/серверами.
  2. На этом сервере работает несколько наших Perl-проектов.
  3. Все кто активно пишут на Perl — пишут и свои модули. Причём не все свои модули можно и нужно выкладывать на CPAN. Все, кто работает над несколькими проектами — используют одни и те же свои модули в разных проектах. Поэтому эта ситуация рано или поздно приводит к необходимости поднять локальное зеркало/оверлей CPAN для своих модулей, чтобы иметь возможность устанавливать и обновлять их «штатными» средствами — это не решает проблему в целом, но жить становится легче. Так что необходима поддержка локального зеркала/оверлея CPAN.
  4. Всегда возникает вопрос: ставить необходимые проекту модули (и свои и CPAN) глобально (напоминаю, у нас свой сервер), или локально. Однозначного ответа здесь быть не может, есть доводы и «за» и «против» обоих подходов. Я для себя определился так: поскольку администрировать (устанавливать, обновлять, отслеживать устаревшие/дырявые версии, удалять) надо все установленные модули, и поскольку невозможно собрать все модули в одном месте (от глобальных модулей избавиться невозможно, т.к. они используются другими общесистемными приложениями, и совсем без локальных модулей обойтись тоже в большинстве проектов не получается), то нужно хотя бы минимизировать количество таких мест и общее количество установленных модулей. Что нас приводит к тому, что большинство модулей должно быть установлено глобально, а локально надо устанавливать модули только в том случае, если версии глобальных модулей не совместимы с конкретным проектом. Да, основной недостаток этого подхода в том, что обновление глобальных модулей может сломать некоторые проекты — но во-первых по моему опыту это происходит довольно редко, а во-вторых используйте тестовый сервер и проверяйте на нём все обновления перед тем, как устанавливать их на рабочие сервера — это ведь надо делать в любом случае, правда? 🙂 В крайнем случае, на роль тестового сервера подойдёт рабочая станция главного разработчика, но минимальное тестирование обновлений необходимо.
Читайте также:  Установка автомобильного электроподогревателя на уаз

Мы уже немного облегчили себе жизнь ограничившись установкой модулей из CPAN-совместимого локального зеркала/оверлея (см. cpansite) и устанавливая большинство модулей в единственном экземпляре глобально. Следующая проблема: глобальных мест установки модулей целых три — core, site и vendor. И из-за этого нередко возникают конфликты. Раньше в Gentoo приоритет был vendor-site-core. Из-за этого устанавливаемые вручную через cpan/cpanplus/etc. в site модули зачастую не были доступны, т.к. в vendor стояла устаревшая версия. И утилиты вроде cpan могли бесконечно выполнять обновление модулей, не понимая, что это ничего не даёт. Решалось это удалением всех модулей из vendor, и прописыванием их вручную в /etc/portage/profile/package.provided, чтобы портаж не установил их снова (после чего надо было внимательно следить во время обновлений системы, чтобы портаж не установил пакеты из dev-perl/* или perl-core/*, и при необходимости доустанавливать эти пакеты через cpan и прописывать в package.provided). Сейчас приоритет site-vendor-core, но это тоже не до конца решает проблему: некоторые (а может и все, я не проверял) core модули, когда обновляются утилитой вроде cpan, устанавливаются не в site, а в core, поверх тех версий, которые установились вместе с самим perl. Это создаёт целых два неожиданных эффекта: во-первых, если в vendor установлена другая версия этих core-модулей (из пакетов perl-core/*), то не смотря на «обновление» модуля утилитой cpan по-прежнему будет использоваться более старая версия из vendor; а во-вторых переустановка пакета dev-lang/perl (например, вызванная revdep-rebuild) откатывает все обновления core-модулей установленные вручную через cpan.

g-cpan

300 модулей, и только для одного из них мне пришлось вручную править ebuild.

В качестве побочного, но приятного эффекта от использования g-cpan мы получаем возможность делать на одном сервере стандартные Gentoo-шные бинарные пакеты для Perl модулей, и очень быстро устанавливать их на остальных серверах (обычная установка модулей, особенно с тестированием, занимает часы, причём некоторые модули ещё и требуют интерактивного взаимодействия при установке).

Установка и настройка
  1. Ставим:
  2. Нужно задать оверлей, где g-cpan будет создавать ebuild-ы:
  3. Задаём свой список зеркал CPAN (включающий первым пунктом наше локальное зеркало/оверлей). Проще всего скопировать уже настроенный список из cpan:
  4. Надо ли тестировать модули при установке — каждый решает сам, но я предпочитаю тесты прогонять, особенно для своих модулей. Чтобы форсировать тестирование perl-модулей при установке, нужно добавить возможность задавать свои хуки на целые категории пакетов. Один из возможных подходов — создать каталог /etc/portage/bashrc.d/ и вот такой файлик /etc/portage/bashrc:
    после чего можно включить тестирование всех пакетов в категориях perl-core/*, dev-perl/* и perl-gcpan/*:
    и, при необходимости, отключить тестирование некоторых модулей или как-то на него повлиять:

Далее, обычно на CPAN самые последние версии модулей — самые стабильные. К нашим приватным модулям это тем более относится. Так что имеет смысл форсировать установку самых свежих версий:

  • Теперь нам нужно обновить индекс CPAN для g-cpan. Теоретически для этого у g-cpan есть опция —cpan_reload, но практически в текущей версии (0.16.2) она не работает. А поскольку g-cpan использует индекс утилиты cpan, то можно обойти эту проблему запустив cpan и выполнив «cpan>reload index».
  • Подготовьте список модулей, используемых всеми Perl-скриптами на сервере. Я обошёлся многоэтажными sh-конвейерами, но, наверное, вам стоит написать для этого Perl-скрипт, и выложить его в комментариях к этой статье. 🙂
  • Генерируем для них ebuild-ы (при этом автоматически будут созданы ebuild-ы и для модулей-зависимостей):
    Есть небольшая вероятность, что для некоторых модулей вам придётся ручками подправить /usr/local/portage/perl-gcpan/Module-Name/Module-Name-version.ebuild. (Мне пока попался только один такой: Crypt::MatrixSSL.)
  • Удаляем каталог /usr/lib/perl5/site_perl/*. ОСТОРОЖНО, в этот момент сломается большинство Perl-скриптов на этом сервере. К сожалению, если site модули не удалить перед установкой vendor модулей (у которых более низкий приоритет), то во время установки и тестирования vendor модулей могут возникнуть проблемы вызванные тем, что будут использоваться site версии модулей уже установленных в vendor. Впрочем, проблемы обычно решаемые, так что если вы не можете себе позволить на некоторое время «сломать систему», то сначала устанавливайте vendor модули, но не забудьте после этого удалить каталог с site модулями.
  • Удаляем все perl-модули из /etc/portage/profile/package.provided.
  • Ставим сначала модули нужные портаж (если использовался package.provided и они сейчас не установлены):
    а потом нужные вам (имеет смысл первыми ставить Test::* модули, потом Math::* — это ускорит установку остальных). Повторяем попытку установки несколько раз, т.к. не во всех модулях корректно прописаны зависимости:

    Обновление

    Полного аналога «cpan>upgrade» утилита g-cpan не предоставляет, запуск
    обновит только модули, пакеты для которых создавал g-cpan (т.е. из категории perl-gcpan/*, а пакеты из perl-core/* и dev-perl/* не обновятся). Но может это и не так плохо — в конце концов для обновления этих модулей, как правило, достаточно скопировать и переименовать ebuild из perl-core/* или dev-perl/* в /usr/local/portage. Зато появляется возможность более тонкого контроля над установленными версиями модулей и удобного отката на предыдущие версии.

    Резюме

    На мой взгляд g-cpan действительно упрощает управление глобально установленными Perl-модулями. И не смотря на громадный раздел «Установка» из 11-ти пунктов, на самом деле ничего действительно сложного там нет (ну, кроме определения какие же модули вам нужно установить :)).

    источник

  • Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *