[devel] spamassassin perl.req

[Alexey Tourbin <at@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 3318 bytes --]

On Thu, Sep 06, 2007 at 04:32:51PM +0300, Victor Forsyuk wrote:
> Тогда еще просьба.
> 
> Сейчас spamassassin собирается только с
> %define _perl_req_method relaxed
> 
> Есть ли шансы улучшить perl.req так, чтобы он смог нормально обработать
> этого монстра?

Вроде собирается.  Он вроде раньше не собирался потому что там была
банальная синтаксическая ошибка в каком-то неиспользуемом или мало
используемом перловом модуле (perl -c тоже не работал, так что я даже
собирался сделать патч, но кажется отключили интернет или не помню
почему так и не сделал).

Зависимости сейчас должны искаться очень хорошо.
Проставляются все зависимости, кроме тех, которые (лексически)
завернуты в "eval {}".  Плюс, в отличие от eval BLOCK, зависимости
в eval STRING вообще не прозрачны.  Но с eval BLOCK есть исключение:
если eval в свою очередь завёрнут в BEGIN, то есть возможность
определить, загрузился модуль в eval или нет (просто через %INC).
В таких случаях завсимость из eval тоже проставляется.

Так что напр. вот такая зависимость на Net::DNS будет проставлена,
если Net::DNS удастся загрузить на стадии perl.req.

/usr/lib/perl5/vendor_perl/Mail/SpamAssassin/Dns.pm
    70  BEGIN {
    71    # some trickery. Load these modules right here, if possible; that way, if
    72    # the module exists, we'll get it loaded now.  Very useful to avoid attempted
    73    # loads later (which will happen).  If we do a fork(), we could wind up
    74    # attempting to load these modules in *every* subprocess.
    75    #
    76    # We turn off strict and warnings, because Net::DNS and Razor both contain
    77    # crud that -w complains about (perl 5.6.0).  Not that this seems to work,
    78    # mind ;)
    79  
    80    no strict;
    81    local ($^W) = 0;
    82  
    83    eval {
    84      require Net::DNS;
    85      require Net::DNS::Resolver;
    86    };
    87    eval {
    88      require MIME::Base64;
    89    };
    90    eval {
    91      require IO::Socket::UNIX;
    92    };
    93  };

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

Так что советую сделать следующее: 1) запустить `buildreq -bi';
2) убрать вообще все зависимости Requires и BuildRequires, проставленные
вручную, кроме, быть может, версионных (если они достаточно актуальны);
3) посмотреть, какие новые пакеты добавляются/удаляются из билдрута при
попытке поставить в hasher (hsh-install) пересобранный таким образом
пакет.

Если автоматический поиск зависимостей Вас полностью устроит,
то желательно запускать 'buildreq -bi' каждый раз после нетривиального
обновления перловых модулей (buildreq может очень сильно оптимизировать
список BuildRequires, что в большинстве случаев предпочтительно, но не
существует корректного способа это "ослабить").

Если в результате что-то не устраивает, пишите дальше.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]