UNИX, осень 2009, 07 лекция (от 18 ноября)

Материал из eSyr's wiki.

• Аудиозапись: http://esyr.org/lections/audio/uneex_2009_winter/uneex_09_11_18.ogg

мы укладываемся до 16 включительно, 23 экзамен.

Сегодня будет двве темы, одна короткая и одна побольше.

В конце будет показательная сборка пакетов.

Сегодня лектор хотел бы попробовать расск. про две вещи:

• Добыча исходников
• Составление спеков.

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

Добыча апстрима это именно шаг 1, а не 0, поск. нам постоянно его надо добывать. Добыча тарболла. Тарболлом исторически называется архив, сделанный архзиватором tape archiver, tar. На сегодняшний день часта ситуация, когда апстрим выкладывает свои творения в виде тарболла.

Ситуации бывают разные. Например, хороша ситуация, когда периодически у п=апстрима случаются релизы, и на sf выкладываются архивы вида name-version.tar.gz. Это пресловутый тарболл. Как правило, в нём содержится каталог name, а в нём все файлы. Это самое как правило, по ощущениям лектора, в 60% случаев. Про остальную треть лектор сейчас расск. В этом случае никаких проблем не возникает, поск. мы скачиваем его и на этом всё заканчивается. В классическом src.rpm есть каталог RPM/sources, где лежит этот тарболл в чистом виде. Правда, дело может осложниться тем, что это не tar, а какой-то некий архив, например, zip, иногда cab и так далее. Поэтому никакой такой зверскойй автоматизации особо не придумаешь, и в классич. файле спецификации, по кр. мере в RPM, .... D LT,BFYT DC` HFDYJ YFLJ FGCNHBV HFPDJHFXBDFNM, и проделывать над ним манипуляции, и по сути дела нет никакого апстрима, есть некий скачаный, развёрнутый и свёрнутый файл. В RPM есть файл исходникоав, разв. автоматом и остальные, разв. руками.

Проблема может сост. в том, что никакого файла с релизом, да ещё с красивым именем, нет. Это свойство не выкладывать тарболлы со снимками стабильных релизов чем дальше, тем сильнее, поскольку народ совсем научился пользоваться VCS, и пока они были централищзованные, ещё можно было объявить релиз, а как только народ перешёл на DVCS, получается так, что непонятно, какую из существующих веток называть релизом. Релизом внезапно называется то,Ю что пошло в хранилище. То же и в апстриме, в какой-то момент говорят, что вот там сцвсте её, и будет вам она. Поэтому задача выкачки апстримного кода пересекается с задачей умения пользоваться VCS.Среди распространённых можно назвать svn, git, hg, bz, cvs. С другой стороны, нужно знать ровно одну команду — как выкачать репозиторий. Высший пилотаж — выкачать опр. ревизию и по тегам.

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

gq: результаты зранения своей работы тоже хотелось бы хранить в VCS, при этом можно использовать git, а для выкачивания --- его бэкенды.

Чем хороош, когда есть релиз: если есть заявленный релиз, то есть жизненный цикл и способ нумерования релизов. Их не так много, и RPM может отличить, что 1.0 меньше 1.12, а не больше. Большинство схем нумерования релизов вполне разумны и вполне поддаются операции больше-меньше, по крайней мере, в RPM он есть. Когда же речь идёт о хранилищах, то там есть ревизия, которая не всегда линейна.

Тут есть одна мелкая неприятность. Она ориентирована на RPM и не актуальна для deb. Проблема в том, что вы не получаете tar, и вам нужно его руками затаривать. Вам в этом случае пирходится проделывать одну лишнюю операцию.

Теперь мы переходим к файлу спецификации.

Сначала на уровне требований подумаем, что должно быть в спеке:

• Паспорт пакета
  • Имя
  • Версия
  • Лицензия. Она обязательна, спасибо господам из дебиана, которые возвели в жёсткое требование, что позв. легко управлять лицензиями в дистрибутиве
  • Описание. Их два: короткое и длинное, при этом описание должно быть сначала на ангглиском, потом может быть на других языках. В дебиане есть специльаное средства для перевода описаний, в RPM ничего такого нет. Вообще идея делать переводы нормальными средствами, а не биением по пальцам ментейнера.

Должны быть ещё две вещи обязательно:

• Группа. Это классификация пакета. Классификаторов очень много, все разные, никакого разумного подхода нет, у альта исторически какая-то классификация. Пример стандартизации классификатора — классификатор freedesktop. Идея там такая, что можно делать сколь угодно малые категории, но, при сборке дерева маленькие категории выкидываются. В RPM классификатор строги, это неудобно, пользователи жалуются, но, с другой стороны, это техническая информация
• Релиз. На самом деле, это патчлевел. Речь идёт о том, что ментейнер собирает один и тот же пакет из одного источника неск. раз подряд. Исправляя ошибки, в случае, если пакет поломался (например, изм. gcc или библиотеки). Ментейнер увеличивает релиз, увеличивая версию.

Это всё паспорт. ТУт ещё указывается

• URL с указанием сайта
• Ссылки на все исходники: Source, Source1, Source2, ... который указывает файлы, из которых собир. пакет. Source развёртывается автоматически. типичный пример — исходник и документация). На саомм деле, это тоже такое фиктивное поле, в слечае, когда никакого тарболла нет. В принципе реком., чтобы поле source собрежало полный url, откуда скачали файл.

Если из одного исх. делается неск. пакетов, то имя, версия, лиензия, описания, группа дублируются. Они обяз. сущ. для всех пакетов, которые собир. для данного исх. В принципе, могут быть разн. версии, ещё что-то разное, но это опционально.

Дополн. требование alt linux --- обыз. наличие поля Packger. Сейчас оно заполн. дост. произвольно, главное, чтобы он был среди ментейнеров. Лектору кажется, что этим проверятсея просто наличие менейнеров. Про acl будет в предпоследний день.

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

Обяз. часть, кажется, закончена, хотя сюда ещё можно добавить секцию files. Она опис., из каких файлов сост. пакет. Их неск. штук для всех пакетов, и там просто указывается, что все файлы из bin, наприме, принадлежат пакету: 'bin/*'

Помимо исходников, в rpm могут входить патчи. Они тоже имеют синтаксис Patch, Patch1, Patch2, ...

Что такое патчи? В случае, если тарболл из апстрима не собирается, или собирается, но не соотв. полиси, то надо поправить исх. перед сборкой. Править прямо в исх. странно, поск. при выходе новой версии эти изм. надо воспроизводить. Есть нес.к вариантов:

• Держать копию
• Делать патчи. Патч --- текстовый файл, где спец. синтаксисом отмечено, как модиф. старый файл, чтобы получить новый.

Чтобы получить патч, нужно сказать diff и созранить результат. Потом при сборке патч будет наложен. Чем это хорошо по ср. руками? Тем, что когда выйдет новая версия можно попытатьс накатить, если изм. пройдут, то шансов на то, что Вы поступили правильно, очень много. А если не пройдут, то это значит, что то самое место, которое Вы изм., изменилось. Кроме того, можно отсылать патчи, они за них иногда говорят спасибо.

Следующий этап --- развёртывание апстрим и его патченье. Эта стадия наз. prep, подготовка. Прежде, чем начать собирать исх. текст, нужно убедиться в том, довести этот текст до сост., чтобы собрка происх. Для этого нужно развернуть тарболл, наложить патчи, разв. другие тарболлы. Возм., нужно запустить другие подг. меры, которые не связаны с проуедурой сборки этого самого исх. текста. Например, поудалять левые файлы, которые апстрим тащит. Например, поудалять готовые configure. Но чаще всего это разв. архивов и патчинг.

Есть макрос %setup, который привязан вот к чему: если файл наз. имя-версия, то он разв. в каталог имя-версия. То в разделе подготовки нужно автоматизировать часто встреч. ситуацию. У этого макроса куча параметров, которая позв. избежать ситуациии, когда имя арзива не совм. с ктаалогом. Поэтому не рек. писать фикт. имён файлов и каталогов. И макрос %patch, который патчит. Смысла в нём большого нет, но количество бкв он сокращает.

Дальше идёт сексия %build, это уже секция собственно сборки. Это самое такое шаманское и прогр. место в ментейнерстве пакетов, которое в лучшем случае сводится к тому, что Вы вып. те инстр., где написано, как собрать. В любом случае, это уже опис. как команды на шелле.

В секциях %prep, %setup, %patch, %build идут шеллскрипты.

%buildroot это место, куда будет происх. установка. Глядя в этот каталог, секция %files, будет решать, что принадл. пакету.

В прнципе, большинство программ расчитано на то, что они будут уст. в пустой каталог. Но это ваша задача, что установка в реальной системе будет происх. в usr, и файлы, которые отн. к данным, нужно искать в ..., библиотеки в /usr/lib, и так далее. Если по умолч. этого не сделано, то он будет уст. в /usr/local. По альтовому полиси, например, этого вообще делать нельзя. Как это выгдл. в реальной жизни: configure --prefix=/usr, --libprefix=/usr/lib, и так далее, при чём в разных сборках по=разному. В альте есть макрос %configure, который разворачивается в большую операцию, где передаются все возм. параметры, которые встречаются в этих configure. Это делается для того, чтобы руками этого не пписать. Если видите, что это делается неправильно, надо посмотреть, и дописать макросу дописать доп. настройки. Предп. такое, что эти все префиксы, они или есть стандартные, или никому не помеш. их переопределение. Настройка файлов для сборки. В этой настройке должны быть указаны реальные каталоги, а при уст. придётся указ. %buildroot. Собираете прогр. как если бы она уст.в наст. систему, а уст. в buildroot. Далеко не все апстримы грамотно пишут, и, возм, придётся руками поработать, чтобы оно делалось правильно.

Соотв., то же самое относится к %make. Мы сейчас рассм. систему configure-make-install, но далеко не всегда так бывает. Тем не менее, если это make? то cnm nfrjq vfrrhjc. Хачем же нужно? За тем же самым.

Помимо %make, есть ещё куча разн. макросов, которые упр. подобные процедуры, например для питона есть макрос для setup.py.

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

Есть макрос %make_buid, которому спуск. количество процессоров, и он запускает make -j.

Тут нужно или исп. --dest-dir, либо писать собственный установщик, который делает то же самое. Соотв. макрос, который наз. %makeinstall, именно так и устроен. Он, собственно, переопределяет кучу каталогов, и переопр. в dest-dir. Но иногда апстрим хочет ставиться в живую систему, поэтому приходиться созд. дерево каталогов.

Некоторые макросы в альте упразднены.

как правило, в секции install раскл. команды по раскл. иконок, документации, и так далее. Которые не предусмотрел апстрим. Обратите внимание, что в этом месте не уч. те файлы, которые явл. документацией к пакету. Две причины:

• У апстрима с этим очень плохо. Обычно доукментация не ставится,поэтому ребята из RPM обр. документацибю отдельным способом.

Остались две секции: files. Она для каждого пакета своя. Тут есть некая хитрость: если пишете files, дефис и какое-то слово, то в рез-те это будут пакеты, принадл. name-слово. Это делается для того, чтобы шаблон в спеке был унифицирован. Идея в том, чтобы имя пакета менялось один раз. У него может быть ключик -f, в котором указываеются файлы, которые должны исп. У setup.py есть ключ, где можно указать, куда складывать все уст. файлы.

Отдельно есть макрос %doc, где указ. путь к документации. Документацией к пакету явл. README, README.alt, который сами напис. В рез-те она кладйтся в стандартное имя в дистр. В альте это /usr/share/doc/name-version. Это позв. самост. выбир, какие файлы в док., во-вторых, это позв. положить док. в стандартное место вне завис. от того, куда её собир. класть апстрим. В files можно указать атрибуты файлов, их принадлежность, по умолччанию всем права правильные. В противном случае исп. это. Некоторые файлы можно помечать как конфигурационные. Некоторые файлы в пакете, которые помечены как конфиг., они обр. иначе в случае переименования и обновления.

Кроме этого ещё есть ГОСТ-файлы, которые соответствуют ГОСТу.

Две вещи:

• Если лектор говорил, что, допустим, такие веши, как rm -r, cp -p перестали быть макросы, то такие вещи, как каталог, где лежат бинарники, иконки, библиотеки, ... --- это всё макросы. Это нужно для того, что если не ровён час поменяется (например, /usr/lib64), ну и вообще это признак хорошего тона.
• Ченджлог. Там запис. изм., которыепроизв. менейнер над пакетом. Кроме того, регламентировано полиси, чтобы у мент. был ключ, и чтобы версия совп. с релизом, который в спеке. В альте есть развесисттое полиси, как обновлять ченджлог. Понятно, заччем нужен ченджлон: чтобы было видно, как его ментейнили.

Чтобы закрыть тему, лектор скажет, что традиционно исп. утилита rpm-build, как альтернатива --- rpm -b, которачя собирает с начала.

Чтобы ментйенёру было удобнее работать, есть промежуточные ключи разные, и у каждой операции есть ключ --short-circuit, который делает только последний этап.

Никакиех спец. инстр, кроме этого, в rpm-based дистр. особо нет, кроме того инстр., который связан со сборкой из git.

gq: было потеряно depend и build-depend

пакету надо указ. зависимости и сбор. хависимости. Поск. в rpm есть зависимости всего одного рода. Сборочные зав. бывают двух видов --- prerequires (

Про зависимости --- в след. раз.

В след. раз ещё поговорим, про то, как помещ. в реп.

Третья секция наз. %install. Установка.