[devel] I: buildreq-src

[Igor Vlasenko]

Уважаемые коллеги,

Хочу представить полезную утилиту buildreq-src
построения BuildRequires: пакета на основе анализа его исходников,
дитем прогресса в области автоматизации.

Пару слов в сторону. Зачем нужен этот прогресс?
Потому что механическая возня с пакетом происходит за счет времени,
которое можно было бы потратить на борьбу с багами и доводку пакета
(интеграцию в дистрибутив). В результате страдает качество, а
повышение качества дистрибутива - главная задача.

Пакетов становится все больше, и чтобы не захлебнуться в их потоке,
нужно искать способы повысить производительность труда.

У нас эта проблема решается с двух направлений.
Дмитрий и Алексей делают большую работу по автоматизации финальных
стадий работы над пакетом -- сборки и тестирования.
Я рою туннель с другой стороны -- исходников. Уже есть места,
в которых эти дороги встречаются, что локально дает фантастический
прирост в производительности - тот же cronbuild, например.

В настоящее время робот импорта сопровождает около 700 пакетов из
Fedora Rawhide. Это скорее смешная цифра по масштабам робота, так как
из одной только Fedora Rawhide можно взять более 5000 пакетов, 
не считая Russian Fedora, Fedora Fusion и еще массы сторонних
репозиториев, а также в перспективе Mageia, Mandriva, SuSE.

С другой стороны, чтобы руками следить за качеством этих пакетов - 
700 это уже не смешная цифра. Рук не хватает, коня приходится
придерживать :( 

Поэтому вырезаю пакеты из дистрибутивов по кускам из похожих
однотипных пакетов, которые при таком подходе легче протестировать.

В настоящее время готовлюсь скормить роботу следующий кусок --
C/C++ библиотеки, которые есть в Fedora, но нет в Сизифе.

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

Не секрет, что многие приложения не собираются в Сизиф, потому что для
них нет нужных библиотек, и многие библиотеки в Сизифе сопровождаются 
по минимуму и только из-за того, что они понадобились для сборки
какого-то нужного приложения. Такие библиотеки-пасынки можно будет 
со временем тоже сбросить на робота.

Дмитрий и Алексей проделали большую работу по автоматизированному
тестированию качества сборки библиотек. Однако это тестирование
производится для уже собранного бинарника, а сборка может уйти не в ту
степь еще на этапе ./configure.
Поэтому, чтобы быть уверенным, что робот собирает библиотеки с
надлежащим качеством, нужен был независимый механизм контроля
сборочного окружения. 

У робота уже есть один такой механизм, это трансляция сборочного
окружения Федоры, подготовленного майнтайнером Федоры, в сборочное
окружение для Сизифа через базу данных DistroMap.

Однако и майнтайнер Федоры тоже человек, и база трансляции
сопровождается по большей части вручную, они могут ошибиться.

Два независимых механизма существенно повышают надежность.
Это если как один предохранитель срабатывает с вероятностью 90%,
то пара независимых предохранителей, с вероятностью 90% каждый,
остановит реактор уже в 99% случаев.

В качестве второго независимого механизма контроля сборочного
окружения была разработана библиотека SourceAnalyzer.
Это библиотека для построения "BuildRequires:" пакета на основе
анализа его исходников. Сейчас SourceAnalyzer в основном только умеет
читать configure.in/configure.ac файлы, зато делает это хорошо.
Для подавляющего числа C/C++ библиотек этого достаточно, а в
перспективе планируется добавить поддержку CMake, Perl, и т.д.

Для файлов configure.in/configure.ac библиотека сейчас понимает более
50 специализированных макросов AC_PATH_*/AM_PATH_*, а также общие
макросы autoconf AC_CHECK_LIB, AC_SEARCH_LIBS, AC_CHECK_HEADER,
AC_CHECK_HEADERS, AC_PATH_PROG, AC_CHECK_PROG, AC_CHECK_PROGS,
PKG_CHECK_MODULES.
В этих макросах производится раскрытие переменных, извлекаются
headers, libs, pkg-config dependencies, затем они пробиваются по
спискам исключений (чтобы не пытаться искать winsock2.h в Сизифе) 
и по базе данных DistroMap DistroDB для Сизифа.
Найденные headers, libs, и т.д. преобразуются в зависимости на пакеты,
либо выдается предупреждение.

Отдельный случай -- это pkg-config зависимости. Их можно
преобразовывать в зависимости на пакеты, а можно выписывать 
в явном виде как pkgconfig(blabla). 

Последний вариант более сильный: если даже пакет blabla и установлен,
но .pc файл в нем удален или переименован, сборка завершится с ошибкой
на этапе ./configure.

Обработка pkgconfig зависимостей осуществляется в зависимости от
опций: можно 
* преобразовывать все pkgconfig(blabla) зависимости в имена пакетов
* держать зависимости в виде pkgconfig(blabla)
* (по умолчанию) добавлять только те pkgconfig(blabla) зависимости,
имена пакетов которых не прописаны в спеке.

Чтобы эту библиотеку можно было использовать вне роботов,
я добавил в пакет perl-RPM-Source-Editor утилиту buildreq-src.

...
(продолжение в следующем письме, чтобы не выйти за лимит в 10k).

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine