Как ВЫ управляете модулями Perl при использовании диспетчера пакетов?

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

, Кроме того, это означает, что наши пакеты могут быть созданы программно (или вручную через оболочку) на любой платформе, куда CPAN работает. Наличие зависимости от диспетчера пакетов влияло бы на Вашу способность распределить Ваше программное обеспечение платформам, которые не используют/поддерживают тот диспетчер пакетов.

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

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

очень легко установить отдельный Perls. Когда Вы работаете, Настраивают от исходного распределения, оно спросит Вас, где Вы хотите установить все. Дайте ему любой путь, который Вы любите. У меня есть многие Perls, установленные в /usr/local/perls, например, и все для каждой установки живет отдельно. Я затем делаю символьные ссылки в /usr/local/bin для них (например, perl5.8.9, perl.5.10.0, perl5.10.0-потоковый). Когда я хочу конкретную версию, я просто использую тот, который я хочу:

$ perl5.10.0 program.pl

конкретный двоичный файл гарантирует, что программа берет правильный путь поиска модуля и так далее (это - тот же материал в модуле Config.pm для того двоичного файла).

Вот сценарий, который я использую для создания символьных ссылок. Это смотрит в каталоге bin, выясняет версию Perl и делает ссылки как cpan5.10.1 и так далее. Каждая программа уже знает, что правильный жемчуг звонит:

#!perl

use 5.010;

use strict;
use warnings;

use File::Basename;
use File::Spec::Functions;

my $perls_directory = catfile(
    $ARGV[0] // '/usr/local/perls', 
    'perl*'
);
die "$perls_directory does not exist!\n" 
    unless -d dirname $perls_directory;

my $links_directory = $ARGV[1] // catfile( $ENV{HOME}, 'bin' ); #/
die "$links_directory does not exist!\n" unless -d $links_directory;

foreach my $directory ( glob( $perls_directory ) )
{
    say "Processing $directory...";

    unless( -e catfile( $directory, 'bin' ) )
    {
        say "\tNo bin/ directory. Skipping!";
        next;
    }

    my @perls = glob( catfile( $directory, qw( bin perl5* ) ) );    

    my( $perl_version ) = $perls[0] =~ m/(5\.\d+\.\d+)\z/;
    say "\tperl version is $perl_version";

    foreach my $bin ( glob( catfile( $directory, 'bin', '*' ) ) )
    {
        say "\tFound $bin";
        my $basename = basename( $bin );

        my $link_basename = do {
            if( $basename =~ m/5\.\d+\.\d+\z/) { $basename }
            else                               { "$basename$perl_version" }
        };

        my $link = catfile( $links_directory, $link_basename );
        next if -e $link;
        say "\t\tlinking $bin => $link";
        symlink $bin => $link or
            warn "\t\tCould not create symlink [$!]: $bin => $link!";
    }
}

Все получает установку в правильном месте для того конкретного Perl.

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

я записал больше об этом виде вещи в Эффективном блоге Perler:

• Делают ссылки на инструменты извращения.
• Управляют Вашими модулями Perl с Мерзавцем.

Я делаю следование всех моих полей:

• я компилирую свой собственный жемчуг: Я все еще использую 5.8. [89] главным образом, запас 5.10.0 имеет регрессию производительности, которая поражает меня много, ожидая 5.10.1, чтобы попробовать еще раз;
• я использую (и настоятельно рекомендую), модуль local::lib для хранения каталога модуля на проект. Прямо сейчас тот каталог является rsync'ed ко всем серверам, где проект установлен, но я тестирую мерзавца использования вместо этого;
• я создаю Задачу:: модуль для каждого проекта, так, чтобы я мог установить все зависимости с единственной командой.

Я использую Debian для разработки и производства, и полагаюсь на debian пакеты Perl, которым предоставляют дистрибутив.

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

Ofcourse, этот метод не без отказов, поскольку много debian модулей жемчуга устарело (по крайней мере, в текущей debian стабильной версии - травление), и бэкпортирование чего-то как Катализатор , который имеет много зависимостей, не практично.

Однако путем доверия диспетчеру пакетов ОС, я сохраняю все замечательные особенности его, которые приносят легкое обслуживание, специально для развернутых серверов, поскольку Вы знаете точно, какие пакеты установлены, и простое apt-get update;apt-get upgrade (от debian, или от локального репозитория) обновляет все серверы до того же состояния, включая модули Perl.

Для производства:

В разработке, выберите версию модуля жемчуга, который кажется правильным для требований; если это возможно, выберите поставленную версию целевой ОС (это делает большинство следующих лишних), иначе, выберите другой. Создайте файл спецификации об/мин для него. Используйте чистую сборку VM для создания об/мин восстанавливаемым способом (от specfile / источник, в котором зарегистрировались на соответствующем ответвлении).

, Когда заключительная сборка может быть создана (после того, как слияние), сделайте ту же сборку от ответвления выпуска, фиксация генерировала RPMs в репозиторий развертывания. Это будет использоваться в заключительной проверке и затем выпускаться к производству, будучи скопированным в производственный репозиторий.

Все серверы в производстве используют тот же самый двоичный файл, который был полностью протестирован; они используют тот же файл спецификации и источник, как разработчик предназначил.

модули Perl НЕ обновлены никаким процессом, который не следует этой модели. Ни любое другое производственное программное обеспечение.

Я также использую оболочку cpan и local::lib.

Вам не должна быть нужна Задача:: для каждого проекта. Просто используйте Модуль:: Установка (мне нравится использовать Модуль:: Начинающий как это:

$ module-starter --mi --module=Module::Name --author="Me" --email=me@cpan.org

и затем просто быстро всовывают Ваши зависимости, требует 'модуля:: зависимость'; в Make-файле. МН Наконец, когда это - время установки, Вы всего perl Makefile.PL (отвечают на да) затем make installdeps

[редактируют 5 лет на от того, когда я дал этот ответ первоначально]

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

Я рекомендую использование только cpan. Модули включают в дистрибутив Linux, только для покрытия зависимости от пакета. При установке Linux без доступа в Интернет только с CD он не может использовать cpan, таким образом, некоторые модули включены как пакеты, но разработчику Perl это плохо.

Также я раньше настраивал cpan для установки модулей в моем доме, (.perl) без корневого необходимого входа в систему.

Я использую порты FreeBSD и оборачиваю все зависимости CPAN в "meta порт" как своего рода локальный порт . FreeBSD имеет настоящее большое количество модулей CPAN и их , система сборки достаточно доступна , что можно легко записать собственный порт, если это не существует - просто не забывают к , отправляют, сказал, что порт , таким образом, это включено в дерево портов. Если порт не имеет текущей версии в запасе, можно всегда редактировать Make-файл для порта, таким образом, это использует новую версию, снова не забывают отправлять изменение :-).

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

Нижняя строка - Как только Вы преобладаете над своей фобией редактирования Make-файлов, порты FreeBSD являются отличным способом поддержать Ваше приложение жемчуга и его зависимости.