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