[devel] QA: проблемы сборки mrtg, вызванные rpm-build-perl-0.5-alt1
Andrei Bulava
abulava на altlinux.ru
Пн Дек 13 10:04:37 MSK 2004
Hi!
Я столкнулся с некоторыми трудностями, попытавшись собрать для Sisyphus
свежую версию mrtg-2.11.0. Во многом благодаря тому, что мне удаётся
отслеживать списки рассылки sisyphus@ и devel@, а также упорству в
чтении журналов изменений пакетов, составляющих мой тестово-сборочный
стенд с Sisyphus, у меня есть основания считать, что корни моих проблем
со сборкой mrtg растут из rpm-build-perl-0.5-alt1.
Чтобы упростить объяснения, я буду рассматривать mrtg-2.10.14-alt1,
который вам достаточно легко получить из текущего Sisyphus для
препарирования - все проблемы одинаковы для новой и старой версий mrtg.
Итак, по порядку. После удачной пересборки mrtg-2.10.14-alt1 в среде
Sisyphus на 10.12.2004 полученный пакет невозможно установить:
$ rpm -Uhv --test mrtg-2.10.14-alt1.i586.rpm
ошибка: неудовлетворенные зависимости:
perl(OS2/Process.pm) нужен для mrtg-2.10.14-alt1
perl(Pod/Parser.pm) >= 1.040 нужен для mrtg-2.10.14-alt1
Первая неудовлетворённая зависимость (её не было при использовании
rpm-build-perl-0.2-alt5, соответствующем времени сборки
mrtg-2.10.14-alt1.i586.rpm в Sisyphus 11.06.2004) возникает от разбора
/usr/lib/mrtg2/MRTG_lib.pm и /usr/bin/mrtg:
$ env RPM_PERL_LIB_PATH=/usr/lib/mrtg2 /usr/lib/rpm/perl.req --verbose
/usr/lib/mrtg2/MRTG_lib.pm
# perl(strict.pm) at line 19 (builtin SKIP)
# perl(SNMP_util.pm) at line 20
# perl(vars.pm) at line 21 (builtin SKIP)
# perl-base >= 1:5.5.0 at line 18 (old perl SKIP)
# perl(Exporter.pm) at line 45 (builtin SKIP)
# perl(Win32/EventLog.pm) at line 1778 (builtin SKIP)
# perl(OS2/Process.pm) at line 1024
# perl(POSIX.pm) at line 1056
/usr/lib/mrtg2/MRTG_lib.pm syntax OK
perl(OS2/Process.pm)
perl(POSIX.pm)
perl(SNMP_util.pm)
$ env RPM_PERL_LIB_PATH=/usr/lib/mrtg2 /usr/lib/rpm/perl.req --verbose
/usr/bin/mrtg
# perl(strict.pm) at line 35 (builtin SKIP)
# perl(FindBin.pm) at line 77
# perl(lib.pm) at line 78
# perl(lib.pm) at line 79
# perl(Getopt/Long.pm) at line 80
# perl(Math/BigFloat.pm) at line 81
# perl(MRTG_lib.pm) at line 84
# perl(SNMP_util.pm) at line 85
# perl(locales_mrtg.pm) at line 87
# perl(Socket6.pm) at line 92 inside eval (SKIP)
# perl-base >= 1:5.5.0 at line 33 (old perl SKIP)
# perl(OS2/Process.pm) at line 102
# perl(Socket6.pm) at line 242 inside eval (SKIP)
# perl(IO/Socket/INET6.pm) at line 242 inside eval (SKIP)
# perl(RRDs.pm) at line 278
/usr/bin/mrtg syntax OK
perl(FindBin.pm)
perl(Getopt/Long.pm)
perl(lib.pm)
perl(locales_mrtg.pm)
perl(Math/BigFloat.pm)
perl(MRTG_lib.pm)
perl(OS2/Process.pm)
perl(RRDs.pm)
perl(SNMP_util.pm)
Хотя в Perl я больше читатель, чем писатель, но на причину
вышеописанного могу указать точно, благо ALM 2.4 с
rpm-build-perl-0.3-alt1.1 оказался под рукой:
$ rpm -ql rpm-build-perl-0.3-alt1.1|xargs grep -10 OS2
/usr/lib/rpm/perl.req-my @ignore_reqs = (
/usr/lib/rpm/perl.req- qr(^Makefile\b),
/usr/lib/rpm/perl.req-# OS-specific
/usr/lib/rpm/perl.req- qr(^machine/ansi\b), # gcc 3.3 stddef.h
(FreeBSD 4)
/usr/lib/rpm/perl.req- qr(^sys/_types\b), # gcc 3.3 stddef.h
(FreeBSD 5)
/usr/lib/rpm/perl.req- qr(^sys/systeminfo\b),
/usr/lib/rpm/perl.req- qr(^vmsish\b),
/usr/lib/rpm/perl.req- qr(^MacPerl\b),
/usr/lib/rpm/perl.req- qr(^Win32),
/usr/lib/rpm/perl.req- qr(\bVMS\b),
/usr/lib/rpm/perl.req: qr(^OS2\b),
/usr/lib/rpm/perl.req- qr(^Mac\b),
/usr/lib/rpm/perl.req- qr(^ExtUtils/XSSymSet\b),
/usr/lib/rpm/perl.req- qr(^Convert/EBCDIC\b),
/usr/lib/rpm/perl.req-# old names
/usr/lib/rpm/perl.req- qr(^Digest/Perl/MD5\b),
/usr/lib/rpm/perl.req-# qr(^Pod/PlainText\b),
/usr/lib/rpm/perl.req-# wrong names
/usr/lib/rpm/perl.req- qr(/\.),
/usr/lib/rpm/perl.req- qr(\$),
/usr/lib/rpm/perl.req-# so commonly used... just a database junk
(guaranteed to be in perl-base)
А вот в rpm-build-perl-0.5-alt1 такое свойство, как "заложенные в ДНК"
ignore_reqs, если и есть, то шаблона с OS2 не содержит :-(
Кстати, это попутно затрагивает вопрос "There's no way to skip a
particular dependency so far.", упомянутый в драфте Perl policy for ALT
Linux Team. Я видел прямолинейный и грубый хак, который был когда-то
реализован мантейнером mrtg в Mandrake Linux - видимо, тоже не от
хорошей жизни: в spec-файле добавляется %define __find_requires
%SOURCEXXX, а сам SourceXXX представляет собой сценарий shell,
вызывающий /usr/lib/rpm/find-requires $* | grep -v 'bad dependency' ;-)
Конечно, это не решение, более правильным было бы дать возможность (с
той самой оговоркой "generally discouraged") добавлять новые шаблоны в
список, аналогичный ignore_reqs из rpm-build-perl-0.3-alt1.1.
Теперь о второй неудовлетворённой зависимости, perl(Pod/Parser.pm) >=
1.040. apt-cache showpkg показывает, что perl(Pod/Parser.pm)
предоставляется пакетом perl-base-5.8.4-alt2, но зависимость не может
быть удовлетворена из-за разницы в формате версий, получаемых
rpm-build-perl-0.5-alt1 и той версией rpm-build-perl, с которой
собирался perl-base:
$ rpm -q --provides perl-base|grep Pod/Parser\.pm
perl(Pod/Parser.pm) = 0:1.14
Думаю, что данная проблема может (и, откровенно говоря, желательно
должна) быть решена и без тотальной пересборки всех пакетов Sisyphus,
содержащих сценарии Perl. Во-первых, я не вижу особого вреда в том, что
избыточная сущность (Serial a.k.a. Epoch) "просачивается" в зависимости.
Во-вторых, rpm-build-perl-0.5-alt1 содержит другие нарушения
преемственности (упомянутое выше изменение поведения в отношении
игнорируемых зависимостей), что ставит под сомнение возможность
полностью автоматической пересборки.
Впрочем, если мотивы удаления Serial a.k.a. Epoch мне более-менее
понятны (удаление избыточности), то относительно "version numbers now
rounded to 3 digits after decimal point" "меня терзают смутные сомненья"
(c). Отдаю себе отчёт, что для вас в этом вопросе моё частное мнение
может ничего и не значить, но... я по своей природе консерватор и
прагматик, поэтому мне нужна серьёзная мотивация для понимания
необходимости такого серьёзного шага в ситуации, когда такой формат
версий не является общепринятым даже для пакета perl-base! Вот избранное
из зависимостей, предоставляемых perl-base:
perl(Attribute/Handlers.pm) = 0:0.78_01
perl(Errno.pm) = 0:1.09_00
perl(File/Compare.pm) = 0:1.1003
perl(Filter/Util/Call.pm) = 0:1.0601
perl(IPC/Open3.pm) = 0:1.0106
perl(Pod/Html.pm) = 0:1.0502
perl(SelfLoader.pm) = 0:1.0904
perl(Text/Tabs.pm) = 0:98.112801
perl(Text/Wrap.pm) = 0:2001.09291
Глядя на "обрезание", произведённое в отношении зависимости
perl(MRTG_lib.pm), предоставляемой пакетом mrtg-2.10.14-alt1, с
perl(MRTG_lib.pm) = 0:2.100001 до perl(MRTG_lib.pm) = 2.100, я проверил,
что же будет с mrtg-2.11.0. Оказалось, что rpm-build-perl-0.5-alt1
найдёт предоставляемую зависимость как perl(MRTG_lib.pm) = 2.100 вместо
действительной perl(MRTG_lib.pm) = 2.100015. Благо, ни для кого эти
предоставлемые mrtg зависимости особой роли не играют, насколько мне
известно.
Я читал о том, что вы предварительно выяснили, каков более-менее
общепринятый формат версий модулей CPAN, и полностью согласен с тем, что
хаосу и бардаку (который, как оказалось, не до конца упорядочен даже в
исходных кодах Perl) нужно положить конец. Со мной только одна беда - я
прочувствовал программирование на своей шкуре до той степени, когда
наступает осознание связи между MAJOR.MINOR.PATCH_LEVEL-версионингом и
изменениями API, ABI или поведения функций, а также приходит понимание
пропасти между системой отслеживания версионной целостности и радостным
сваливанием JAR'ов, PM'ов и пр. в помойку, гордо именуемую lib, на
головы несчастных мантейнеров... и при этом никак не владею умением
донести своё понимание до других.
В общем, мотивируйте меня, а дальше, если получится, то мы будем
действовать сообща. "Массовая гипноиндукция, позитивная реморализация.
Гипноизлучатели на трёх экваториальных спутниках" (c) ;-)
--
// AB1002-UANIC
Подробная информация о списке рассылки Devel