Re: [devel] [#56408] DONE (try 52) perl.git=5.14.2-alt1 srpm=perl-Filter-1.39-alt1.src.rpm ...

[Alexey Tourbin <at@altlinux.ru>]

On Mon, Oct 24, 2011 at 11:38:22AM +0400, Girar Builder robot wrote:
> http://git.altlinux.org/tasks/archive/done/_55/56408/logs/events.52.2.log

Мужчины, я собрал perl-5.14!  А также обновил или пересобрал все бинарно
зависимые пакеты.  Крупных разломов не предвидится.

Основное изменение - организационное: я расконвертировал большую часть
своих перловых пакетов из git в src.rpm.  Это связано с тем, что эти
пакеты будут обновляться роботом, о чем разговоры идут давно, а теперь
имеются и некоторые предварительные договоренности.  По этой же причине
я взял на себя смелость расконвертировать и чужие перловые пакеты, а также
привести спек-файлы к более унифицированному виду.  Про автоматическое
обновление пакетов - чуть ниже.

Расконвертирование и унификация коснулись только перловых пакетов,
публикуемых на CPAN, включая проекты с отдельным сайтом, такие как
gtk2-perl.sf.net, которые тем не менее регулярно выкладываются на CPAN.
С остальными пакетами я обходился осторожно.

Пару слов про пересборку пакетов под perl-5.14.  Во-первых, несколько
API-макросов перестали давать lvalue, которому можно присваивать.
Типичное исправление выглядит так:

	-	GvCV(sv) = NULL;
	+	GvCV_set(sv, NULL);

Ещё не все апстримы успели выпустить версии с исправлениями такого рода;
а некоторые выпустили только совсем недавно.  Поэтому, например, я решил
сразу во время пересборки обновить postgresql с версии 9.0.4 до 9.0.5.

Во-вторых, и это очень важно, перловый код теперь должен компилироваться
с родными для перла CCFLAGS.  Точнее, на архитектуре i586 весь перловый
код должен компилироваться с флагом -D_FILE_OFFSET_BITS=64.  Это связано
с тем, что в структуре "struct interpreter" имеется поле "struct stat",
размер которого зависит от _FILE_OFFSET_BITS.  Соответственно, когда мы
хотим прочитать какие-то поля из "struct interpreter", которые расположены
после "struct stat", то без правильного значения _FILE_OFFSET_BITS можно
промахнуться и прочитать совсем не то.  В результате может при загрузке
модуля может появиться такое сообщение об ошибке:
	
	Not a CODE reference at /usr/lib/perl/DynaLoader.pm line 207

Типичное исправление может выглядеть так (spec):

	# do not override default CCFLAGS
	sed -i '/CCFLAGS/d' Makefile.PL

или так (Makefile.PL):

		use Config;
		...
	-	CCFLAGS => $cflags,
	+	CCFLAGS => $cflags . ' ' . $Config{ccflags},

Видимо, красивого решения этой проблемы не существуют.  В дебиане
тоже исправляют пакеты "по одному", примерно таким же образом.
Так что я не стал придумывать специальный хак, который бы принудительно
проставлял нужные флаги.

* * *

Некоторые соображения об автоматической сборке пакетов.

Понятно, что среди всех пакетов перловые пакеты наилучшим образом подходят
для автоматической сборки.  Потому что процедура сборки пакетов
унифицирована, потому что почти все пакеты содержат тесты, которые
выполняются при сборке по умолчанию; а при поиске зависимостей ещё
выполняется syntax check - короче, получить битый пакет не так-то просто.
Потому что CPAN отдаёт информацию о пакетах в актуальном структурированном
виде.  И, не в последнюю очередь, потому что перловых пакетов много - 1350+,
то есть почти 11% от общего числа, если считать src.rpm пакеты в сизифе.

Что должен и чего не должен делать робот, чтобы обновить пакет?  Моё
представление об этом такое.  Рассмотрим робота первой инкарнации v1.0.
Этот робот должен делать следующее: скачать новый тарболл в каталог
SOURCES, изменить версию в спекфайле, и попытаться получить src.rpm пакет.
Нужно проверить, что в полученный src.rpm пакет "всосался" новый тарболл -
это произойдёт, если поле Source в спекфайле параметризовано.  Тогда
полученный src.rpm пакет можно отправлять на сборку.

Суть в том, что больше робот v1.0 вообще ничего делать не должен.
Не должен смотреть даже ниже поля Version в спекфайле!  К сожалению,
робот, с которым мне приходилось сталкиваться, ведёт себя слишком
остроумно: первым делом редактирует поле Source и часто добавляет
зависимость на perl(Module/Build.pm), причём в неподобающем месте.
И вообще демонстрирует неуёмную тягу к редактированию спекфайла.

Вообще, у робота не должно быть задачи максимизировать число пакетов,
которые он с грехом пополам может автоматически обновить.  А именно, должна
быть четкая линия демаркации - это навеяно идеями Поппера - что существует
штатная ситуация и класс пакетов, которые поддаются автоматическому
обновлению, а остальные пакеты автоматическому обновлению не поддаются,
т.к. требуется квалифицированное вмешательство.  Соответственно, сдвигать
линию демаркации вправо - это авантюрная идея; а робот, который может
обновить любой пакет несмотря ни на что - это плохой, негодный робот.

Рассмотрим робота следующей инкарнации, v2.0.  Что ещё полезного может
сделать робот?  Наверное, все же стоит попытаться собрать пакет в хешере,
прежде чем отправлять его на сборку.  Но стоит ли, например, проверять
после этого неудовлетворенные зависимости?  Полноценная проверка требует
перегенерации репозитория (для замещения пакетов).

Вообще, робот сидит в своем маленьком мирке и выполняет некоторый
ограниченный набор операций по комплектованию пакетов.  А сборочная
система для робота трансцендентна, какие проверки там дальше будут
выполняться, это для робота непостижимо.  Но всё же робот контролирует
некоторую первичную реальность, из которой потом получается смысловая
реальность.

Эти смутные рассуждения наводят меня на мысль, что робот должен
контролировать список файлов в собранных пакетов.  А именно, в простейшем
случае в хешере робот должен собирать пакеты с опцией
_unpackaged_files_terminate_build.  А лучше будет сравнивать сборку
старого и нового пакетов: если появились новые незапакованные файлы,
то скорее всего мы получаем недоукомплектованный пакет (и такой пакет
нельзя отправлять на сборку).

Дело в том, что на последующих этапах - при проверках в сборочной системе
и т.п. - диагностировать все последствия недоукомплектованных пакетов
будет довольно трудно.

Кроме того, есть ещё один неприятный момент, который можно назвать
переукомплектацией.  Дело в том, что *.pl файлы, находящиеся в основном
каталоге, по правилам MakeMaker устанавливаются в /usr/*/perl5/Foo/,
наряду с lib/ и другими файлами.  Так что в дерево модулей иногда
попадают файлы типа /usr/*/perl5/Foo/benchmark.pl или Bar/bug123.pl,
которые порождают левые зависимости.  Так что это даёт ещё одно правило
для робота: если появились файлы /usr/*/perl5/*/*.pl, которых раньше не
было, то не следует автоматически отправлять пакет на сборку.