Для чего различные каталоги в @INC, используемой?

См. Политика Debian Perl в отношении путей для обоснования и использования всех, кроме первого и последнего из них. Я предполагаю, что / etc / perl будет для модулей, которые содержат только данные конфигурации, а / usr / local / lib / site_perl для совместного использования, не зависящего от архитектуры, не зависящие от версии модули с Perl, не входящим в пакет Debian?

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

/usr/local/perls/perl-5.10.0/lib/perl5/darwin-2level
/usr/local/perls/perl-5.10.0/lib/perl5
/usr/local/perls/perl-5.10.0/lib/5.10.0/darwin-2level
/usr/local/perls/perl-5.10.0/lib/5.10.0
/usr/local/perls/perl-5.10.0/lib/site_perl/5.10.0/darwin-2level
/usr/local/perls/perl-5.10.0/lib/site_perl/5.10.0
.

Системы сборки Perl потенциально распознают три типа установочных каталогов, о которых вы можете прочитать в ExtUtils :: MakeMaker ] или Module :: Build :

• core - для материалов, поставляемых с сайтом Perl
• - материалов, устанавливаемых локальным пользователем
• поставщика - материалов, устанавливаемых поставщиком ОС для вас или через их систему пакетов

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

Debian имеет свою собственную политику , которая, на мой взгляд, немного сложна, но это работает для них.

Система ActiveState действительно настроена как решение, в основном управляемое ActiveState, так что вы можете устанавливать все через PPM. Их больше всего беспокоят стабильные и проверенные корпоративные установки, где они выполняют большинство задач за вас. Если вы хотите делать все самостоятельно, вы используете Strawberry Perl, который также имеет простую структуру каталогов модулей.

Я не использую Perl от Apple для своих собственных вещей, но у них тоже дурацкая настройка:

/System/Library/Perl/5.8.8/darwin-thread-multi-2level
/System/Library/Perl/5.8.8
/Library/Perl/5.8.8/darwin-thread-multi-2level
/Library/Perl/5.8.8
/Library/Perl
/Network/Library/Perl/5.8.8/darwin-thread-multi-2level
/Network/Library/Perl/5.8.8
/Network/Library/Perl
/System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level
/System/Library/Perl/Extras/5.8.8
/Library/Perl/5.8.6
/Library/Perl/5.8.1

Вы также можете найти недавнюю запись Шверна Use.perl в core / vendor / site полезной в качестве справочной информации.

Я думаю, это потому, что есть много способов установить модуль - cpan, tar.gz, deb package - и все они стараются не связываться с чужими вещами.

При поиске модуля очень удобно использовать% INC. В нем хранятся имена всех модулей и места, откуда они загружаются.

Например, при запуске:

perl -MDBI -e 'print join "\n", map { $_ . " = " . $INC{$_} } keys %INC'

Выдает мне:

XSLoader.pm = /usr/lib/perl/5.10/XSLoader.pm
warnings/register.pm = /usr/share/perl/5.10/warnings/register.pm
Carp.pm = /usr/share/perl/5.10/Carp.pm
Scalar/Util.pm = /usr/lib/perl/5.10/Scalar/Util.pm
Exporter/Heavy.pm = /usr/share/perl/5.10/Exporter/Heavy.pm
vars.pm = /usr/share/perl/5.10/vars.pm
strict.pm = /usr/share/perl/5.10/strict.pm
Exporter.pm = /usr/share/perl/5.10/Exporter.pm
List/Util.pm = /usr/lib/perl/5.10/List/Util.pm
warnings.pm = /usr/share/perl/5.10/warnings.pm
DBI.pm = /usr/lib/perl5/DBI.pm
AutoLoader.pm = /usr/share/perl/5.10/AutoLoader.pm
Config.pm = /usr/lib/perl/5.10/Config.pm
DynaLoader.pm = /usr/lib/perl/5.10/DynaLoader.pm

Это удобно, особенно когда модуль устанавливается несколько раз в разные места.