Роман Химов

В прошлую пятницу мне приспичило опробовать создание дебьяновских пакетов. Вроде как RPM-ок насобирался в последнее время немало, а deb-ов ни одного. Что обидно, конечно. Ну, стало быть и попробовал собрать. Выбрал пакетик нехитрый, да забавный и поехали.

Пакетиком оказался Cutecom. Этакая QT-шная замена minicom с некоторыми приятными отличиями. Принялся паковать. А точнее, читать. Много читать. Очень много читать!..

Руководство для начинающего сопровождающего (человеку, который, наконец-то, перевел слово ‘maintainer’: СПАСИБО!!!) пакета в Debian — 59 страниц. Руководство для разработчиков Debian, куда постоянно ссылается руководство для начинающего сопровождающего — это документ на 116 страниц. Справочник по стандартам Debian, куда постоянно ссылаются оба два документа — еще 138 страниц, причем, это без дополнений.

Объемы неслабые. Но надо понимать, что сходу все читать бессмысленно (ибо мозг не переварит), поэтому пошел я прям по инструкциям по созданию пакета и таки его создал. Это интересно. Debian, это явно не RPM.

С одной стороны, мне сходу не понравился сам факт того, что приходится создавать нечто в самих распакованных исходниках пакета (каталог debian и все его содержимое). В RPM как ни крути, все проще и даже, не побоюсь сказать, логичнее. Мухи и котлеты раздельно — оригинальные исходники сами по себе, все патчи сами по себе, spec выступает рецептом по смешиванию и приготовлению блюда.

Далее идет распространение изменений в виде единого diff-а «исходный пакет -> дебьянизированный пакет». Спорная вещь. С одной стороны, вроде как уже и .src.rpm не нужен. С другой стороны, ведет к представлению всех изменений в виде единого diff’а, а это зло.

Тут, однако, можно использовать dpatch или еще чего и помещать в debian/patches нормальные штучные патчи. Собственно, так делает абсолютное большинство сопровождающих, поскольку иначе работать сложно. Можно даже использовать quilt, что вообще радует, поскольку знакомо, просто и понятно. В принципе, несложно организовать работу так, что все будет даже несколько удобнее, чем в RPM, поскольку каждый патч для создания RPM должен быть прописан в рецепте, spec-е, соответственно, добавление-удаление вынуждает каждый раз его дергать, здесь же можно просто пользоваться спец-инструментом для управления патчами (тот самый quilt) и жить спокойно.

Но, собственно, это не главное в пакетах Debian. Главное в пакетах Debian — это руководства и стандарты. Это процедуры. На мой взгляд, RPM-ки создаются все же проще, но они создаются так как они создаются. Debian же — это стандарты и если в стандарте сказано, что каждая программа должна иметь страничку мана, значит так должно быть.

Попробуйте ввести ‘man konqueror’ в Fedora или еще где, ничего не увидите. В Debian — пожалуйста, полноценный ман с описанием всех параметров. И так для каждого приложения. Исключения бывают, но крайне редко, причем, исключения считаются ошибками, которые следует исправлять. Аналогично, например, с добавлением графических приложений в менюшки графических же оболочек. Нельзя просто скомпилировать и пнуть приложение в релиз.

Именно через это образуется единство стиля и качество дистрибутива. Отнюдь не через магическую пакетную систему, которая используется только в Debian и сородичах. Различие пакетных систем здесь играет малую роль, особенно после появления yum в RPM-ных дистрибутивах.

Разница в подходах технически местами тоже интересна. В RPM spec — это рецепт. В нем есть несколько оговоренных полей, несколько стандартных стадий сборки, для каждой из которых можно писать желаемые действия в виде скрипта с использованием макросов. В Debian для сборки пишется вполне полноценный Makefile, что, как мне кажется, несколько расширяет возможности, хотя в большинстве случаев эти возможности не будут востребованы. Все остальное, что не касается сборки (описательная часть, так сказать), расфасовано по оговоренным заранее файликам в каталоге debian.

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

И тут идут процессы. Как я уже говорил, Debian — это стандарты и процессы. Важны обе части. Но самое главное, что обе части тщательно задокументированы и следование им практически гарантирует успех.

Для начала, например, стоит объявить о намерении создать пакет через систему отслеживания ошибок Debian. К счастью, это не Bugzilla, можно воспользоваться reportbug (вот только не из Ubuntu, а то не туда уйдет) или просто написать письмо в правильной форме. После чего, можно демонстрировать свой пакет менторам и искать спонсора, который пакет положит в архив Debian.

Как результат, я радостно забил свой ITP (Intend to package). После чего заслал описание и ссылку на пакет в debian-mentors. После чего тут же получил дельный список на 14 пунктов о том, как можно улучшить мой пакет. 🙂 Незамедлительно устранил все недочеты, представил новый пакет и, о чудо! Пакет ушел в архив Debian (ветка unstable, конечно), а у меня появился спонсор. 🙂

Однако, как водится, чистый и неподдельный идиотизм иногда пробивает брешь в любой защите и в любой процедуре. 😉 Так и получилось с cutecom. Я, конечно же, проверял, есть ли такой пакет уже в Debian, но, как водится, что-то как-то проверил не так. В результате получилось, что я «обокрал» человека, который до этого успел сделать пакет для предыдущей версии cutecom и являлся его сопровождающим. Новый пакет (мой), просто-напросто ставил меня в сопровождающие и дело с концом (кстати, заливка пакета в архив автоматически закрывает баги, достаточно написать «Closes: bug#…» в ChangeLog, так закрылся мой ITP).

Это, естественно, некрасиво и так делать низзя. Поэтому, пришлось писать повинную и каяться. Однако, предыдующий сопровождающий оказался человеком спокойным и, коль уж такое дело, передал мне сопровождение пакета.

В общем, теперь я сопровождающий маленького, но очень гордого пакета в Debian (что видно тут, только там еще версия, в которой cutecom отнесен к разделу x11, сегодня с утра я обновил пакет, теперь cutecom находится в comm). Спасибо Jorge Salamero Sanz и Daniel Baumann, соответственно, сопровождающему предыдущей версии и спонсору!