С прошлого раза должок про спек, лектор пост. его закрыть сегодна. Лектор хотел расск. более подробно про зависимости. Во-первых, понятие сборочной зависимости --- то, что нужно для сборки пакета, зависимость --- то, что нужно для работы. В дебиане есть только один вид зависимости, но там тоже есть всякие тонкость. Anyway, эта инфромрация о зависимостях обязана присутствовать в спеке. ЗАчем? Ровно потому, что робот, собирающий пакеты из src-rpm, он пост. в изолир. среду только те пакеты, которые указ. в сбор. зависимости. Это можно делать по-разному: Можно, например, ставить все пакеты и собирать так, можно собирать на своей машине, правда, это актуально только для прошлого тысячелетия. Со сборочными завис. есть одна единст. проблема, которуюстоит озвучить. Вот, есть поргр. продукт, который научились собирать. Вы, собирая этот продукт, понаставили кучу разных инструментов. Всё это, кстати сказать, неавтоматизированно, с другой стороны, есть пакеты xorg-devel, kde-devel, такие мощные штуки, но позв. поставить их и после этого собирать.

Для получения сборочных завис. исп. buildreq. Он через ld_preload вешает обработчики загрузки библиотек и созраняет эту инф. На самом деле, это огрубляется, но тем не менее.

Допустим, для сборки нам нужны n+1 библиотека. Кто их поставит? Их поставит какая-то часть процедуры сборки, которая форм. поле requires. На эту тему в альте написано довольно многоразвесистых программ, которые опр. список зависимостей, тому шо сделать ldd это самое простое, а есть ещё import в питоне, условный импорт... Поле requires есть, туда частенько что-то вписывать, но это обычно вида... вот есть игрушка, её движок, хорошо бы ему в requires поставить демку. Или пакет плагинов...

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

Что касается спека, то на сама деле имеет смысл договорить две веши. Одну вещь. Во-первых, про макросы: в RPM есть очень замороченная, но очень мощная система макросов, простая система слов с процентиком, которая разв. в довольно большие посл. символов. Например, макров %make_build, точно также есть спец. вспомог. макросы для пакетов, напис. на интерп. языках, поск. так есть заморочки с версиями, с полиси... ЗАчем всё это нужно? затем, чтобы польз. как меньше писать.

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

Немного про патч и дифф. Берётся программа. Она не собирается или не работает. Пытаетесь собрать, находите ошибки, исправляте, и так далее до того момента, пока не соберётся. После чего делается дифф --- diff -ur. Хорошим тоном является созд. диввапосле каждого исправления. Это, во-первых, позв. читать эти патчи, во-вторых, помогает в случае, когда исправили в новой версии только чатсь патчей. Кроме того, есть repatch, когда если патч применился с неким fuzz, то генерится новый патч, есть возм. сравнения диффов.

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

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

Хранилище это орг. особым обр. дерево каталогов.

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

Когда сизиф рядом, напримеР, зеркалируется, то можно класть новые пакеты туда, тогда после сборки можно сказать apt-get update? apt-get dist-upgrade, после чего в системе будет уже новый пакет. Это не то, чтобы провозирует к проверке, но созн. ментейнер будет это делать. В случае, если пакет собирается на сбороч. сервере, то с него копируете, после чего можно, конечно, сказать apt-get install, но это нетривиально, если их несколько. То есть процедура становится долгой и неавтоматизированной. В принципе, никто эту программу не мешает поставить в хэшер и погонять её оттуда, поск. хэшер польз. своим репозиторием. Но понятно, что это не боевое тестирование.

Лектор обр. внимание ещё натакой факт: традиционно считается, что ментейнер польз. своим пакетосм. Если зайти на сизиф, то это традиц. предст. неверно. Тем не менее, очень плохим тоном считает сборка пакета без его тестирования.

На этом лектор умолкает про тек=стирование. Отсюда две вещи:

Возм., лектор недост. уделил внимания src.rpm. Это не пакет, поск. он не имеет свойств пакета. Это архив, где есть RPC/Sources и RPM/Spec. Тем не менее, именно этой инф. достаточно, чтобы собрать rpm из src/rpm.

Последняя на сегодня тема --- обр. связь, сопровождение пакета.

Если вы ментейните пакет, то неплохо бы в нём разираться и разбираться в его окружении, напр., если ментейните пакет на питоне, то неплохо бы обновить пакет при обн. версии питона. В общем, неплохо бы следить за инф. простр. вокруг пакета. Чтобы не оказ. в ситуации, что пакет стал нерабочим, а Вы продолж. им польз. Кроме того, ыбло бы неплохо участв. в списках рассылки, принимать активное участие в соотв. ресурсах.

BTS, bug tracking system. исп. для отсл. ошибок в программе. Есть тенденция объединять BTS, веб-морду репозитория, ... в один портал.

Два замечания:

Что вообще может быть на типичной системе отслеж. ошибок такого дост. большого сообщ., как альтлинукс:

Какая структура:

У ошибки есть два параметра --- приоритет и сложность. Приоритет её влияет на то, как быстро её надо исправлять, а есть менее приор. ошибки. Что касается severity, то понятно, что синт. ошибка в док. она дост. нулевой тяжести, а ситуация, когда всё падает, то это тяжёлая ситуация. Но практика показ., что даже квалиф. польз. не может расст. в этом двумерном пространстве правильные коодринаты.

Что ещё есть в BTS? Уведомление о повешенных ошибках получит ментейнер а также всякие связанные лица: группа контроля качества, все опдписавшиеся, выпуск. дистрибутива. К каждой ошибке, как правило, прилаг. цепочка обсуждения. В процессе обсужд. могут появл. патчи, могут изм. сост. ошибки.

Ошибка моджет иметь разл. состояния. Только повешенная, принятая к сведению, дальше неск. вариантов исправлений:

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

На очереди --- рассказ про текушее сост. дел в сизифе и как это сейчас делатеся, как жизнь ментейнера меняется в Сизифе, изапланироваться показ. сборку пакета.

LecturesCMC/PackageMaintaining2009/Conspects/08/eSyr (последним исправлял пользователь eSyr 2009-11-26 15:34:17)