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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Он сам пользуется тем, что он ментейнит, и никто другой до него не додумался пакет собрать, или ментейнер был да сплыл.
• Второй мотив в том, чтобы собирать прогр. для кого-то

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

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

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

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

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

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

• Чтобы разб. в source-based дистр., надо разбираться во всём сразу. Почему: потому что если оно не собралось, то надо это поправить.
• На самом деле, квалификации там больше, а инстр. по сопровождению меньше. Да, есть опр. конвенции, да, есть движение вперёд по тому, как прогресс. спеки s-b дистр., но это всё дост. небольшие шаги по причине изначального положения вещей. В случае, когда мы имеем дело с bin-based дистр., пользователь не то, что лишён такой возм. (в приличнвых дистр. можно и пересобрать пакет), но вас никто это делать не обязывает. Поэтому, вся ответственность за работу пакета ложится на ментейнера.

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

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

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

• Устанавливается ли вообще пакет.
• Если уст., то вопрос, можно ли в нём работаьт.

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

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

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

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

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

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

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

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

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

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

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

• Нельзя автоматизировать процесс отправки ошибок в апстрим
• Если мент. мотивирован прогр. собирать, то он мотивир. её и исправлять

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

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

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

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

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

• Крутым сист. администратором. Нужно осв. дост. небольшой объём знанию по администрированию --- максимум, что потр. --- созд. ручное зранилище
• Крутым прогр., в особенности на всяких промышл. языках.
• Профессионалом в предментой области ПО.

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

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

• Ментейнеру нужны знания соц. плана.
• Нужны знания в обл. сообщ. и дистр, в рамках которого он работает
• Должен уметь хотя бы немножко программировать на ЯП, желательно, на всех
• Должен хорошо себе предст., как устр. ОС, должен быть весьма продвинутым пользователем
• Ментейнер должен проявл. соц. активность.

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

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

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

• Списки рассылки. Списки рассылки всё ещё ост. более разумным и грамотным ресурсом, чем те же форумы. Прежде, чем задать вопрос в списке рассылки, лучше сначала его поискать в списке рассылки.
• Собственно инф. ресурсы, сайт сообщества, типа altlinux.org. Там наверняка будет инстр. нач. ментейнеру, там же пример, там же всякая информация.
• Исх. тексты других пакетов как примеры (by example).

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

• В первую очередь лектор идёт на искалку RPM, ищет src.rpm нужной софтины, чаще всего попадается fedora, потому что там самый большой rpm-репозиторий, скачивает его, уст. лок. репозиторий, удляет две трети ненужного и собирает. Чаще всего работает. На всякий случай просм. спец и переходит к стадии тестирования. Процедура эта занимает совсем там.

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