[devel] spamassassin perl.req
Alexey Tourbin
=?iso-8859-1?q?at_=CE=C1_altlinux=2Eru?=
Чт Сен 6 19:21:15 MSD 2007
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, что в большинстве случаев предпочтительно, но не
существует корректного способа это "ослабить").
Если в результате что-то не устраивает, пишите дальше.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20070906/8734fe19/attachment-0001.bin>
Подробная информация о списке рассылки Devel