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

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

Третье, о чём ммы поговорили, это то, кто такой ментейнер. Мы рассм. структуру сообщ. (ядро, деятели, пользователи). С точки зр. сообщ. вокр. дистрибутива таким вот деятелем становится ментейнер. Этот человек имеет дело не столько с продуктом, сколько со сборкой. Задлачча его в том, что перед ним лежит некий тарболл (комок смолы), и его задача --- из тарболла сделать пакет. Этот вот путь требудет от человека специфических знаний и более-менее унифиц. для разных сообществ.

мы поговорили также о том, какие свойства придаём пакетам.

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

Наконец, поговорили о том, что нужно для обесп. сборки пакета. Для того, чтобы собрать пакет, нужно много чего проделать: обесп. свойства пакета. Соблюсти policy.... В результате получается нечто более организованное, чем тарболл.

Ещё мы поговорили про то, что эта стандартная процедура по напихиванию в имеющихся список фалойв по напих. свойств, ноа тоже имеет свою градацию.

Всё это приводит к тому, что эту сборку сделать как можно более воспроизводимый.

Именно этот процесс и поддерж. ментейнер.

Видимо, надо начать не с того, какими инстр. он польз., а с мотивации.

Зачем и почему люди становятся ментейнерами?

Вспоминаем, что мы в сообщ., и тут не фильтруется вход в сообщество по намерениям. Это общее утверждение.

На саомм деле, больших ситуаций ровно две:

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

Есть третья мотивация --- JFF. Чиловеку интересно получаться экспириенс, и лектор знает таких людей. Но это маргинальная ситуация. После этого человек или втягивается и действ. пред. причины, или не втягивается.

Лектору неизвестны ...

Тут нужно сделать одно маленькое замечание: почему лектор до сих пор в Альте. Бонус в следующем (это и есть илл. того, почему становтяся ментейнерами): если к лектору попадает программа, которой ещё нет, то он начинает ею пользоваться. Но у лектора, как у человека с опытом преследует опасение, что при обновлении чего-нибудь оно сломается и придётся опять шаманить. В какой-то момент времени масштабирование возьни с тарболами начинает быть выше масштабирования возьни с пакетами. Обратное тоже верно: если в жизни не больше трёх раз предст. восп. данной программой, то лектор не будет делать из неё пакет. Кстати сказать, с этим связано забавное наблюдение: почему такие продукты, как веб-движки, неохотно лезли в пакеты до посл. времени: представьте себе человека, который много где ставит веб-движки. На саомм деле, это довольно редкая ситуация, обычно деплоят один раз. Почему сейчас ситуация изменилась --- поотму что за работу по тиражированию веб-движков взялись дистрибутивостроители. Это пример, когдапоявляется мотивация по опакечиванию какого-то софта.

Это к вопросу о мотивации.

Лектор забыл расск. об одной вещи, дополнение к позапрошлой версии --- когда мы будем говорить про ментейнерство, в превую очередль будем говорить о ситуации, когда исп. binary-based дистрибутивы. Есть ещё source-based, где сначлаа ставится комплиятор, потом всё собираете из исх. текстов. Примеры --- BSD-дистр., Gentoo, LFS. Мы будем говорить не об этой традиции, которая жива и процветает, а о традиции постр. дистр. на осн. binary-хранилищ. Причин две

Это нас плавно подвоидт к тому, что собственно делает ментейнер. Что должен сделать ментейнер. Единственное, что он должен делать от начала до конца --- составить спек. Для того, чтобы сделать из тарболла пакет, что нужно сделать:

  1. Сборочное окружение. Это сильно зависит от сообщества, техн. ресурсами которого вы пользуетесь.
  2. Получить рабочий исходник ("добыть ups"). Upstream имеет свойство программировать, и появл. новые версии. Перед тем, как делять пакет, нужна скачать какой-то тарболл. Почему лектор про это вспомнил: есть средства автоматизации этого безобразия, свзанные в первую очередь с тем, что файлы зранятся в какой-то VCS, и вместо того, чтобы заставлять их тарить, а потом у себя разворачивать, вытаскивать исх. из репозитория. 1.В этом сбороч. окр. он должен сост. спецификацию. Если у Вас Ваш тарболл распрост. на условиях копилефта, то файл спецификации также автоматически включается в список исх. и тоже должен расп. на условиях не хуже. Надо понимать, что люди, которые берут gpl-ный софт, делают бинарник, и потом тыкают в исходные сорцы, они не правы. действия тоже принадлежат к исходникам.
    • Как получается спец: автоматич. способа генер. нет. В сообщ., где специ развесистые, часть этой развесистости можно сгенерировать автомтаически, но чаще всего это именно то, что ментейнер пишет, его творчество, тот текст, с которым больше всего имеется времени.
  3. Предположим, что запросто так из тарболла сделать пакет невозможно. Тогда приходится залезать не только в спек, но и исправлять исходники. Для того, чтобы не вып. сизифов труд, эти испр. принято оформ. в виде патчей. Что это значит? Это значит, что если вы вносите изм., то их вы должны отнложить в отдельном месте, и тогда файл спец. будет выгл. след. образом: взять тарболл, внести испр. и потом только собирать. Этот процесс тоже можно автоматизировать, например, держать два дерева исходников. И в момент, когда надо соббирть пакет, можно получить дифф. Гдк-то между этими двумя лежит такая штука, как профилирование сборки --- куда что класть.
  4. Проверить, работает ли пакет. К сожалению, практика показывает, что, в зависимости от того, чем мотивирован ментейнер, он может пропускать. Что, на самом деле, не есть хорошо, и тут как раз надо смотреть на область мотивации. Если человек действ. активно польз. той порграммой, которую сопровождает, то тестирование можно за скобки вынести, а в ситуации, когда человек разминается, это вот не очень хорошо. Иогда бывает так, что ментейнер пакетом не польз., и пакет не трогают,потому что есть живой ментейнер.

Тестирование сост. из двух частей:

Лектору неизв. на сегодняшний день сообщ., в которых есть стандартизованный testsuite для запуска программ. Тестирование того, устанавливается ли пакет (нет ли в нём unmet, нет ли в нём неразрешённых символов), такие вещи автоматизируют. Можно даже извратиться и сост. глобальный список всех предост. символов всех пакетов в хранилище и проверять. В любом случае, такие вещи можно сделать, а вот проверку, что пакет работает, их нет. И если для скриптовых вещей ещё можно напистаь, то для ряда других пакеетов оно непонятно.

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

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

Сейчас лектор не готов назв. поимённо, какие езщё процедуры происзх. при приёме в хранилище, но они происх.

Зимой-весной было акт. шевеление в Сизифе, что пакеты долго собираются, а при помещ. их в сборочную среду sisyphus-check ругается. Это тоже творч. решение ментейнера --- написать спек так, чтобы выполнялись ещё и глобальные рповерки, не только локальные.

Если Вы думаете, что на этом всё заканч., то это не так, тут всё только начинается. Поск. это однократное действие, а ментейнинг, ..., ну, если ты попал, то ты попал. Потому что задача менейнера --- сопровождать пакет дальше.

Послений пункт --- собственно сопровождений

Допустим, выходит новая версия. Мы возвр. к шагу 0.

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

Главное, и, пожалуй, живое, то, что делает механизм сообщ. дистр. живым --- поддержка мех. обр. связи по ошибкам. Когда правильный польз. находит ошибку, или несообразность в пакете, которым польз.

Багзилла --- это адапт. под нужды разр. инстр., который позв. сообщ. пользователю о том, что прогр. не работает. Сообщ. о нераб. прогр. не пойдёт в апстрим, пойдёт в дистр.:

Никто не мешает посылать туда и фичреквесты, например, об обновлении пакетов.

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

  1. Это должен быть человек, в дост. степени компьютеромотивированный, хотя бы мотивированный прогр. продуктом: нужно не лениться смотреть апстрим, смотреть багзиллу.
  2. Главное знание ментейнера --- знание спец. того зранилища, в рамках которого он работает. Нужно уметь грамотно сост. спецификацию, нужно зорошо знать packaging policy: куда класть файлы, какие исп. макросы. Здесь возм. дост. низкий старт, объём знаний нач. не велик, но это то место, соверш. в котором ментейнеру не помешает.
  3. Вообще говоря, поск. в обяз. мент. взодит сборка и посл. испр. пакетов, то было бы неплохо хотя бы поверз., но обшир. знание о инстр. сборки прорг. продуктов. Можно и обойтись без этого, но такой члеовек недолго в мент. пробудет. Необх. в знаниях разн. инст. и ЯП знать хорошо, но необязательно. Здесь возм. дост. большой люфт професс. навыков, тружно будет скорее не сообщ., а вам. Сюда же отн. знание специфич. инстр. разработки: patch, diff. Есть мнение, что в будущем это тоже не очень понадобится.
  4. Тестирование. В прниципе, что кас. тест. продукта, хорошо бы хотя бы знать, для чего пакет нужен, или найти человека, который её может оттестировать. Иначе будет не очень хорошо.

Попробуем просуммировать:

Кем не явл. метнейнер:

Резюме: менетейнер не обязан быть крутым.

С другой стороны:

Кто же это такой: достаточно закончить ВМК, чтобы быть хорошим ментейнером, потому что тот небольшой задел во всех областях именно то, что нужно ментейнеру. Хотя это и не обязательно, он может набрать где-то ещё немноог знаний по обширному количеству тем. Должен ли он быть профессионалом? Необязательно.

Чтобы закривыть эту тему с другой стороны: нет такого учебного заведения, где бы вам выдали тот набор знаний, который нужен для ментейнерства от начала до конца. Это связано со структурой того знания, которое нужно иметь, с его широкополостностью. Поэтому вы увидите всякую инф. для мент. на сайте сообщ. Технический сайт сообщ., там будут тусоваться именно ментейнеры, это именно то места, куда надо ходить за инф. Инф. рес. сообщ. --- это именно то место, откуда инф. черпает ментейнер.

Какие бывают инф. ресурсы:

Чтобы закрыть тему: как лектор собир. пакет.

Лектор думает где-нибудь в конце встреч устроить показательную сборку пакетов.

LecturesCMC/PackageMaintaining2009/Conspects/04/eSyr (last edited 2009-10-22 11:20:16 by eSyr)