OBS - openSUSE Build Service или "Одна Баба Сказала..."

/*

дамы и господа,
это - первая заметка о некоторых трюках при работе с замечательным сервисом openSUSE/Novell - openSUSE Build Service. если Вас интересуют какие-то детали или Вы желаете задать вопрос - оставляйте комментарии. постараюсь ответить.

недавно прислали очень поучительный экспромт о занятиях с детишками в детском саду. его и буду использовать в качестве "оглавления". поехали...

Занятие для организованных детских групп ДДОУ "Детский садик Светлячок".
Тема: "Автодорожное движение".
Учитель громким голосом четко произносит фразу, оканчивая ее вопросительной интонацией.
Дети хором произносят ответ.

УЧИТЕЛЬ: Кто король далеких трасс?
ДЕТИ: КАМАЗ!

абсолютно верно и пгавильно подмечено! формат rpm - наше фсио! остальное - от лукавого. а как же убунту и ".deb"? - очень неудобно разбираться откуда ноги растут у "dh_make". другими словами: spec файл - это святая Библия, где всё написано от и до. если встретился непонятный макрос - например %configure - набираем:

> rpmbuild --eval %configure

и смотрим что именно он означает. хотим написать свой макрос? - легко! читаем:

man rpm
vim /usr/share/doc/packages/rpm/manual/macros

и заглянем в "/usr/share/doc/packages/rpm/manual/" из чистого любопытства - там таки есть что почитать перед сном. по сравнению с rpm другие форматы пакетов выглядят как набор костылей. и не надо мне рассказывать, что EBUILD (Gentoo) рулит. любое использование USE флага автоматом означает невозможность стандартизировать результат и, как следствие, непригодность этого поделия в Production. а все типа "оптимизации", получаемые при "гибкой" сборке, можно спустить в унитаз чуток обновив железо. кроме того, rpm никоим разом не мешает делать спецсборки софта для тех же кластерных вычислений или же для работы с видео (как пример).

Что же такое этот OBS (openSUSE Build Service)? это система, которая позволяет создавать пакеты для всех основных дистрибутивов Linux, включая RH, Debian, Ubuntu и иже с ними. ежели по-простому, то внутрь ты пихаешь исходники и инструкцию по сборке, а на выходе получаешь готовые красивые КОШЕРНЫЕ пакеты. кошерные - ибо существуют некоторые наборы правил, которые мейнтейнер (далее буду пользовать термин "упаковщик") обязан соблюдать. под правилами также подразумевается наличие систем проверок готовых пакетов. то бишь устанавливая пакет из OBS лузер (в теории) имеет возможность полностью проконтролировать сборку и увериться, что ставит "кошерный продукт".

УЧИТЕЛЬ: Кто гремит и весь в пыли?
ДЕТИ: Жигули!
УЧИТЕЛЬ: Кто проедет грязь игриво?
ДЕТИ: Нива!
УЧИТЕЛЬ: Кушай кашу "Геркулес", купит папа?
ДЕТИ: Мерседес!

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

* вы прониклись мощью и красотой решения, получили учётку в Novell, создали свой домашний проект и, при помощи Web-gui (броузера) сваяли свой первый пакет.

* пакет этот нихуя не собирался как надо до тех пор, пока вы не прорюхали великий смысл в строках "BuildRequires: список DEVEL-пакетов (через пробел), необходимых для сборки Вашего первенца"

* всё собралось, но не везде. вы ещё раз пофтыкали инструкцию как компилять для разных дистрибутивов, обматерили всех "умников", дающих разное название одинаковым сущностям/пакетвм, взмолились о глобальной стандартизации, но таки сваяли новый spec файл.

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

* у Вас оформилось светлая мечта уебать аффторов "проверок" чем-нить тяжёлым по умной голове, послать всю затею с OBS куда подальше и "включить идиота" на полную катушку - "Какие мейнтейнеры? "ПРЕВЕД" надо говорить разработчикам. Очнитесь. Задача мейтейнеров проста как 2x2- собрать из сырцов бинарики, собрать их в пакеты с учетом зависимостей, и положить их правильную ветку. Они вобще не должны "допиливать" что то до ума." - это высказывание одного из неофитов, отрицающих очевидное. "незнание законов не освобождает от ответственности"©

УЧИТЕЛЬ: За рулем бандитский тип, а машина эта?
ДЕТИ: Джип!
УЧИТЕЛЬ: Оштрафует, хоть ты тресни - это дядя?
ДЕТИ: ДэПээС-ник!
УЧИТЕЛЬ: Кто не дружит с головой? Это дядя...
ДЕТИ: Постовой!

дабы не уподобляться "дяде, что не дружит с головой" таки стоит осознать несколько прописных истин, как то:

* любые правила упорядочивают хаос;
* в данном контексте существующие проверки ставят целью обезопасить конечного Пользователя и указать "упаковщику" на некоторые очевидные оплошности в пакете;
* врага надо знать "в лицо"!

изучением этого "врага" и предлагаю заняться далее.

текущая система проверок уже готовых пакетов состоит из двух независимых друг от друга уровней (другими словами: в какой хронологической последовательности собранные пакеты проходят эти проверки - совершенно не важно). первый - это rpmlint проверки. детальное описание оных вы найдёте по ранее приведённой ссылке. мы можем полностью их контролировать. в секции "Supressing False Positives" описана методика подавления "фиктивных" ошибок. но, как всегда собственно, есть "нюансы"... о них и поговорим.

перво-наперво читаем:

> man rpmlint

после чего смотрим на детали (если нам жуть как интересен сам механизм проверок):

> rpm -ql rpmlint

потом начинаем разбираться в том, "виноват" ли rpmlint в ошибке со сборкой нашего пакета. понять это очень просто. если проверка говорит, что "(Badness: 10000)" (допустим) - то это "наш" rpmlint. также он очень вежливо пишет какая именно из множества предусмотренных проверок "отоварила" нас выигрышем в джекпот:

permissions-file-setuid-bit (Badness: 10000) /usr/bin/БИНАРЬ is packaged with setuid/setgid bits (04555)

вежливо благодарим за предоставленную информацию и чешем репу. в данном конкретном примере нам сделали серьёзную предъяву, что собираемый нами пакет есть злобное некошерное чудовище, которому не место на системах добропорядочных граждан. однако, иногда (в ОЧЕНЬ редких случаях) наличие SUID-bit оправдано. предположим, что это именно такой случай. задача - поблагодарить OBS за предоставленную информацию и вежливо попросить заткнуться на будущее (не навешивать пакету штрафных очков).

* создаём в "исходниках" файл с расширением ".rpmlintrc". допустим Ваш спек называется "ПЕРВЕНЕЦ.spec", тогда созданный только что файл должен называться "ПЕРВЕНЕЦ.rpmlintrc"

* добавляем инструкцию насчёт нашего "проблемного" (по мнению OBS) бинаря:

addFilter("permissions-file-setuid-bit.*.*")

мы только что поставили монолитную могильную плиту над всеми попытками rpmlint-а заорать, что наш пакет имеет плохой SUID-bit на бинарнике. это конечно же неправильно. конечно же надо разобраться в вопросе и попытаться как-то обойтись без подобных крайностей. поэтому всем рекомендую перечитать одну из моих прежних заметок, где история именно с этой проверкой "моего" пакета расписана от "А" до "Я". кроме того, там есть пример "умной" brp проверки, о которой наша речь пойдёт далее. фраза "as responsive as a wall" почему-то постоянно приходит мне в голову применимо к данному случаю... интересно, что бы сказал по этому поводу дедушка Фрейд?

обращаю внимание публики, что файл "ПЕРВЕНЕЦ.rpmlintrc" не обязательно вносить в "ПЕРВЕНЕЦ.spec" как "Source?:". это конечно же диктуется правилами хорошего тона, но... увы и ах.

мы все, к сожалению, живём в реальном мире, а любые проверки подразумевают некий "идеальный мир" (сугубо с позиций АВТОРА проверок), к которому надо стремиться. это и есть суть возможных конфликтов. "What we've got here is a failure to communicate..." /Guns'n'Roses/


УЧИТЕЛЬ: Десять трупов, все в кисель, в ДТП у нас?
ДЕТИ: Газель!
УЧИТЕЛЬ: Кто на встречной всякий раз?
ДЕТИ: Пида@ас!
УЧИТЕЛЬ: Мигалки, @ляди и понты, за пивом ехали?
ДЕТИ: Менты!

второй эшелон "обороны" - это появившиеся в версии openSUSE-11.1 так называемые "brp" проверки. информации о них - море (попробуйте найти хоть одно внятное описание в openSUSE Wiki). как пример можно сразу смело давить на эту ссылку поиска и чесать репу до полного просветления. удачи.

официальная точка зрения по этому вопросу такова (несколько упрощённый вариант ессно): "brp проверки - наше фсио! отключить их нельзя! все пакеты должны проходить проверку brp!" лучше всего об этом скажут воспитанники детской группы ДДОУ "Детский садик Светлячок":

УЧИТЕЛЬ: Красный свет горит не зря, нету хода?
ДЕТИ: ни @уя!

на данный момент все пакеты для openSUSE-11.1/Factory проходят "brp" проверки в обязательном порядке. к чему приводит подобный подход - уже описывал. "благими намерениями вымощена дорога в ад"© - что есть, то есть. в основе-то своей идея стоящая. разработать правила, которым должны следовать все. только реализация хромает. наличие неких "белых списков" для якобы "кошерных" пакетов, куда всем прочим никогда не попасть, ставит на этой идее могильный крестик. махонький такой, ибо есть "нюансы", о которых и поговорим ниже.

суть "brp" проверок очень бледно отражена в трёх пакетах:

brp-check-suse | build root policy check scripts | package
brp-check-suse | relaxed build checks | patch
librpcsecgss | Library Implementing GSSAPI Security for ONC RPC | package

сами же "проверки" уже "зашиты" в пакет "rpm" ("зашиты" - это неправда!). можно на них полюбоваться кстати:

> rpm -ql rpm | grep brp | grep -w "rpm"

или

> find `rpm -ql rpm | grep brp | grep -w "rpm" ` \
-print -exec cat {} \;

делов-то. а на самом деле посмотреть на механизм проверок можно (imho) только в случае установки и запуска локально сервера OBS. "brp" проверки именно "зашивают" в конфигурацию проекта/платформы. например: в openSUSE-10.3/11.0 их нет, а в openSUSE-11.1/Factory они есть.
другими словами, разрешено всё, что не запрещено. спектр проверок довольно широк. от "правильно" (по мнению авторов ессно) сформированного "*.desktop" файла и до уже упомянутых ранее "некошерных" сервисов D-BUS (без которых повторюсь не будут работать пакеты типа "Wicd", "Exalt" и прочие). с одной стороны это здорово - нахуя в openSUSE лишние пакеты? да и если Вы хотите собирать для openSUSE Community - то есть же Packman! (в Packman Community communication skills более развиты кстати...) с другой же стороны это вполне может привести к тому, что в OBS в первую очередь будут собирать пакеты для RH/Ubuntu/MDK, а потом чесать репу насчёт сборки для текущей версии openSUSE. именно эту картину все и наблюдали в момент релиза версии openSUSE-11.1. доступного софта по сравнению с версией 11.0 было значительно меньше, ибо "упаковщики" в течение следующего полугода старались "вытянуть" свои проекты на уровень 11.0.

на сегодня о сути проверок можно догадываться по именам файлов, их содержащим. в скобках - моё imho:

00-check-install-rpms (этот пакет вообще может быть установлен... производится реальная установка пакета в chroot-е)
01-check-debuginfo (проверка на "пустоту" в пакете -debug)
02-check-gcc-output (насколько серьёзны были предупреждения компилятора во время сборки. для проверки используется реальный лог сборки пакета)
03-check-binary-kernel-log (что-то связанное с корректной установкой бинарей, хотя хз, запамятовал)
04-check-filelist (собсно проверка содержимого пакета на соответствие его "таможенной декларации")
05-check-invalid-requires (ибо нехер рисовать кривые зависимости ручками, да!)
06-check-installtest (если вы думаете, что вы тут самый умный и наколбасили левые %pre*/%pos* скрипты/макросы - то самое время сходить нахуй)
08-check-permissions (весьма здравая идея, но сам тест - мог быть и получше...)
09-check-packaged-twice (безобидный тест на "декларирование" в %files файла дважды/трижды/etc)
10-check-lanana (хз)
11-check-pkgconfig-deps (если Ваши "*.pc" файлы - файлы для "pkg-config" - содержат некорректную информацию - пришло время ревизии!)
12-check-libtool-deps (очень тупой и бесполезный тест, ибо правила хорошего тона рекомендуют к буям вырезать из пакета все {*.a;*.la} файлы - мамо, оно нам не надо...)
13-check-invalid-provides (на тему излишнего усердия при ручном заполнении строк "Provides:" - эти поля очень неплохо заполняются автоматически и не надо тут особо вы@бываться)
14-check-gconf-scriptlets (хз, не попадались)
99-check-remove-rpms (проверка на успешное удаление пакета с реальной деинсталляцией из chroot)

всё, что приведено выше, на первый взгляд пропитано самой Добротой и Заботой о ближнем (и о дальнем, что характерно), но в реальной жизни появляются... да-да-да! "нюансы"...

одно из отличий "brp" от "rpmlint"-а в том, что "плохие отметки" (Badness: X) "brp" тебе не ставит. ежели чего не так - ты сразу же идёшь нахуй в пролёте вместе со своим собранным пакетом под звуки фанфар, бурные апплодисменты и без лишних объяснений.

разберём типовую ситуацию. есть дивный блок проверки "*.desktop" файлов, который иногда неимоверно бесит. одна из "выдающихся" проверок может не найдя иконки (упомянутой в пресловутом *.desktop файле!) допустим в %{_datadir}/pixmaps/ сказать:

ERROR: Icon file not installed:

и отправить тебя вместе с пакетом в путешествие пешком. как минимум есть два случая, при которых эта "проверка" абсолютно бесполезна:

1) если иконка установлена в %{_datadir}/icons/ (да, не по фэн-шую, но работает!)
2) если мы не хотим рисовать свою иконку и тянуть в зависимостях к нашему пакету какую-то из доступных тем иконок (что imho абсолютно оправдано и разумно. ну не будет в xdg менюшке у нашего горе-приложения иконки, и что?).

пишем письмо по адресу, упомянутому в OBS, предназначенному для решения подобных "неувязок" - stbinner@suse.de . идём нахуй, ибо ещё в октябре-декабре прошлого года этот Товарищ поменял e-mail, а о новом ящике простые смертные не знают ничегошеньки. естественно, что после этого мы получаем нехилую мотивацию послать "brp" ф пизду исправить в пакете все недочёты, обнаруженные милыми "brp" проверками. такая возможность конечно же есть (пока что).

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

удачи.

P.S. планируется в недалёком будущем рассмотреть некоторые аспекты работы с OBS при помощи Web-gui и командной строки, описать процесс создания "One-Click-Install" файлов, рассмотреть создание модулей ядра и просто попиздеть о том о сём... пишите камменты, они рулят!

*/