[devel] QA: проблемы сборки mrtg, вызванные rpm-build-perl-0.5-alt1

[devel] QA: проблемы сборки mrtg, вызванные rpm-build-perl-0.5-alt1

[Andrei Bulava]

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] Re: QA: проблемы сборки mrtg, вызванные rpm-build-perl-0.5-alt1

[Alexey Tourbin]

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

On Mon, Dec 13, 2004 at 09:04:37AM +0200, Andrei Bulava wrote:
> А вот в rpm-build-perl-0.5-alt1 такое свойство, как "заложенные в ДНК" 
> ignore_reqs, если и есть, то шаблона с OS2 не содержит :-(

Шаблон для OS2 был забыт при переносе из perl.req в B/PerlReq.pm.
Это ошибка.

> Кстати, это попутно затрагивает вопрос "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' ;-) 

Некоторое врмя назад я предлагал автоматизировать (или "легализовать")
именно такой способ:
	Date: Wed, 26 May 2004 03:21:38 +0400
	Subject: [devel] %NotRequires/%NotProvides RPM macros

> Теперь о второй неудовлетворённой зависимости, 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

Это обсуждалось и я писал об этом в этой рассылке.  Это, подгтовка
perl-5.8.6-alt1 была закончена ещё вчера и он поступит в Sisyphus,
вероятно, в ближайший рабочий день.  В этот же день рассосётся unmet
на Pod::Parser.

> Думаю, что данная проблема может (и, откровенно говоря, желательно 
> должна) быть решена и без тотальной пересборки всех пакетов Sisyphus, 
> содержащих сценарии Perl. Во-первых, я не вижу особого вреда в том, что 

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

> Впрочем, если мотивы удаления Serial a.k.a. Epoch мне более-менее 
> понятны (удаление избыточности), то относительно "version numbers now 
> rounded to 3 digits after decimal point" "меня терзают смутные сомненья" 
> (c). Отдаю себе отчёт, что для вас в этом вопросе моё частное мнение 
> может ничего и не значить, но... я по своей природе консерватор и 
> прагматик, поэтому мне нужна серьёзная мотивация для понимания 
> необходимости такого серьёзного шага в ситуации, когда такой формат 

Скажите, вы читали тред -- ?
	Date: Wed, 1 Dec 2004 22:33:08 +0300
	Subject: [devel] RFC: perl deps versioning

> версий не является общепринятым даже для пакета 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 зависимости особой роли не играют, насколько мне 
> известно.

Дело просто в том, что это "обрезание" необходимо -- для того, чтобы
уравнять requires и provides с точки зрения rpm, который не понимает
десятичной точки.  Отсутствие обрезания также способно порождать
unmet'ы. Эти unmet'ы в некотором смысле и существовали, просто они не
были заметны из-за того, что разрыв между требуемыми и предоставляемыми
перловыми модулями был очень велик и не доходил до десятичной части.
Например, --

	Provides: perl(Module.pm) = 3.10
	Requires: perl(Module.pm) = 2.100

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

> Я читал о том, что вы предварительно выяснили, каков более-менее 
> общепринятый формат версий модулей CPAN, и полностью согласен с тем, что 
> хаосу и бардаку (который, как оказалось, не до конца упорядочен даже в 
> исходных кодах Perl) нужно положить конец. Со мной только одна беда - я 
> прочувствовал программирование на своей шкуре до той степени, когда 

	Я всею скробью скорблю мировою,
	Грудью дышу я всем воздухом мира...

> наступает осознание связи между MAJOR.MINOR.PATCH_LEVEL-версионингом и 
> изменениями API, ABI или поведения функций, а также приходит понимание 
> пропасти между системой отслеживания версионной целостности и радостным 
> сваливанием JAR'ов, PM'ов и пр. в помойку, гордо именуемую lib, на 
> головы несчастных мантейнеров... и при этом никак не владею умением 
> донести своё понимание до других.
> 
> В общем, мотивируйте меня, а дальше, если получится, то мы будем 
> действовать сообща. "Массовая гипноиндукция, позитивная реморализация. 
> Гипноизлучатели на трёх экваториальных спутниках" (c) ;-)

Уж давайте тогда и вы меня мотивируйте.
За пузырь...

> -- 
> // AB1002-UANIC

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

Re: [devel] Re: QA: проблемы сборки mrtg, вызванные rpm-build-perl-0.5-alt1

[Andrei Bulava]

Alexey Tourbin пишет:

<skip/>

> On Mon, Dec 13, 2004 at 09:04:37AM +0200, Andrei Bulava wrote:
> Шаблон для OS2 был забыт при переносе из perl.req в B/PerlReq.pm.
> Это ошибка.

В bugzilla или уже принято вами в расчёт?

<skip/>

> Скажите, вы читали тред -- ?
> 	Date: Wed, 1 Dec 2004 22:33:08 +0300
> 	Subject: [devel] RFC: perl deps versioning

Перечитал ещё раз - "вопросов больше не имею". Если б у меня на момент 
написания письма был под рукой архив devel@, я бы не уселся в лужу, 
задавая уже отвеченный вопрос. А память уже не та, чтоб помнить детали 
прочитанного больше недели назад. Спасибо за вашу подсказку.

<skip/>

> Уж давайте тогда и вы меня мотивируйте.
> За пузырь...

Ладно уж, признаю - был неправ, пузырь за мной ;-)

-- 
// AB1002-UANIC