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

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

  1. Надо следить за апстримом, апстрим может ломать исходники, по другому относится к окружению -- за всем надо следить.
  2. Но есть и вторая часть -- надо следить за хранилищем. Даже если вы еще не сопровождающий, вы как собиратель базируетесь на каком-то хранилище. По крайней мере, если вы разумный человек. Это означает, что всякие изменения в хранилище могут ударить по работосопособности и собираемости.

Что может произойти?

  1. Обновления библиотек. В ситуации, когда вы не член тим вам приходится глазками или дополнительными сведениями пользоваться чтобы понять, с какими билиотеками вы собираетесь. Может сломаться сборка, может, что хуже, собраться и не работать.
  2. Обновления тулчейна. Типичный пример -- вышел новый гцц, в нём ещё строже относятся к синтаксическим конструкциям. И ваш пакет перестал собираться, или тесты перестали проходить. Нет ничего хуже, чем просто отклюить эти тесты -- надо разбираться. Ещё истории -- например, проводится полиси по более жесткому алгоритму сборки. Очень многие апстримы не заморачиваются указанием последовательностью указания обж при компиляции, но если это требовать, то появляется плюс -- линкуются только функциональные зависимости, а не "все х библиотеки". Следующий разлом -- дсо линк. В результате был авыброшена рекурсивная компановка библиотек. Если вы собираетесьь с кем-нибудь, кто собирается с либм, то либм вы явно не пишете. Вы ничем не рисковали, а теперь рискуете -- дсо линк это ещё более строгое указание библиотек, которые вы используете, и либм надо указывать явно, если вы используете из него символы. Неудобно, потому что не у всех этот дсо линк включен, а удобно потому что опять ы увас сгенерируется бинарник, который будет требовать только нужные. Наоборот, он делает зависимости не иерархическими, а прямыми. Всякое такое изменение сопровождается двумя эффектами
    1. стало ещё менее удобно это собирать
    2. стало ещё более удобно это делать сообща
  3. Вообще с хранилищем могут происходить самые разные вещи. Например, пропал пакет и единственный выход -- самому его собирать. Как вы понимаете цельность и работоспособность зависит не только от того, как гео написал автор, но и от того, где и с чем вы собираетесь.

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

Хранилище

  1. Это исторически просто сайт, на котором лежат все пакеты для сборки дистрибутива из них. Это была эпоха ноль. Бинарник + исходник. На те поры идея была простая -- кто чем богат, тот тем и рад. С некоторой ненулевой вероятностью они собирались. В те времена тысяча пакетов в хранилище было много, код писали медленно, кода было мало. Главный недостаток -- недоверие бинарному хранилищу -- пакет собранный у кого то будет работать или нет. Главная проблема -- синхронизация сборочных окружений. Если мы договорились, что бинарный пакет собирает каждый сам у себя, то надо делать это в одинаковом окружении. Хорошим тоном было держать у себя зеркало хранилища, обновлять его рсинком, обновлять пакеты и только потом заниматься сборкой. Всё это делалось под честное слово, но если человек соблюдал чётко прописанное полиси, то вероятность того, что полученный бинарник будет запускаем было доаольно высокий. Правда при этом необходимо было вести строгий контроль сборочных зависимостей, чтобы ненароком не собраться с тем, чего нет в репозитории или чтоб не забыть написать зависимость в пакете. Здесь правда довольно быстро пришли на помощь роботы. В альлинуксе findref findprop -- глядят на пакет и формируют список не указанных майнтейнеров сущностей, которые требуются для данного пакета и список сущностей (виртуальных пакетов) которые этот пакет предоставляет.В эту же сторону идет альтовый сетвершн. Библиотека провайдит множество имен, бинарник требует подмножество имен.
  2. Эпоха поменялоась, когда сообщество устало от локальной сборки и перешли к сборке на сборочнице. Все наши разговоры о изолированной сборке связаны с тем, что современные дистрибутивы не формируются из приватных сборочных окружений, а всякий пакет попадает в хранилище в виде исходников, потом собирается в сборочнице и именно этот пакет выкладывается. Бонус -- вероятность того, что пакеты, собранные на одной сборочнице установятся и будут работать вместе -- достаточно велика. Есть исключения -- обновления тулчейна, обновления библиотек. Какая главная роблема у сборочницы -- первая проблема -- проблема неизолированность сборки, когда результат одной сборки влияет на другую сборку. Было несколько инструментов, общая идея в том, что наша сборочница, которая работает не переставая, раюбботала в изолированном окружении. Хэшер -- типичный пример. Главная проблема осталась -- неудовлетворенные зависимости. Что такое неудовлетворенне зависимости? Этьо ситуация, когда вашем хранилище находится пакет, который нельзя поставить, потому что ему нужно что-то, что никто не провайит. Если не предринять никаких действий, то очень много никак не связанных с процессом сборки деййствий, приводящий к тому, что репо ломается. Типичный пример -- обновление чего-нибудь общенужного. Увеличилась, грубо говоря, вышла новая библиотека с обновлением аби и сонейма, и это означает, что новая версия билиотеки не булет провайдит нужные вритуальные функциональности и все пакеты, которые их требовали перестали собираться. Вышел новый либхмл, в нем поменялось аби, программы могут не заработать. Это детектится на уровне проверки зависмостей. Сколько лектор помнит работу в альтлинуксе -- сколько пользовались репоиторием такого типа -- борьба а анметами была главной проблемой. Если среди пакетов встретятся такие, которые входят в сборочное окружение, то первая же попытка собрать пакет приведет к ошибке. Можно написать автомат, который будет пытаться установить каждый пакет из хранилища, чтобы проверить, не появились ли анметы. Рассылать письма счастья "попытайтесь пересобраться". Но это накладывает условия на существование хранилище. Есть всегда нестабильное хранилище. Пользоваться им в продакшне могут только одноразовые каскадеры. Почему? Потому что там что-то с гарантией не работает, если повезет, то не работает ненужное. Темне менее, но для сборки пакета в хранилище необходимо это самое икс ноль. Значти, первое что надо -- изолированная сборка, чтобы собирать в нестаблильном, а работать в стабильном. Ещё нам надо хранилище первого уровня, которое либо без анметов вообще, либо с лимитированным числом анмета. Для простоты будем считать, что анметов нет. Икс один замкнуто по зависимостям. Как из ноль организовать один? Очень просто. У нас есть хранилище ноль. Выбираем базовый обхем пакетов, например бейз-систем, который замкнут по зависимостям, и переносим в икс 1, а потом начинаем переносить пакеты, окторые не ломают зависимостей. Исключение --- кольцевые зависимости, которые надо таскать группой, а не по одному. Получается исходное хранилище с дырками на месте анметов. С течением времени с новым либхмлем все пересоберутся и оно переедет в хранилище один. Разница будут только в окончательно выброшенных пакетах и в версиях. Списочный состав будет похож, а версионный разный.

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

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

Есть эшелонированное хранилище, и минимизируем количество анметов так, чтобы в икс один был как можно меньше

1. Разработка -- обычное состояние.

1. Замарозка -- необычное состояние, ошибкой считается наличие анмета.

1. Выпуск.

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

Ситуация, когда есть компания вендор такое не проходит. В таком случае дистрибутивом считается блин, сд. У компании разработчика есть обязательства, есть техническая поддержка, есть идея -- для чего нужен дистрибутив. То есть вот эта картинка дополняется вот чем.

Происходит ветвление.

Репозиторий уровня икс ноль продолжает развиваться.

А репозиторий уровня икс один начинает допиливаться до состояния, чтобы не все множство пакетов, а то, которое входит на сидюк, обладало вышеуказанными свойствами.

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

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

резудьтат -- у вас будет базовое хранилище и регулярно вылезающие из него ветки, в которых будет все меньше и меньше изменений и в конце концов они будут выбрасываться.

Пример такого -- убунту. Как вы видите разница только в размере, никто не ставит себе задачу сделать дистрибутив размером с всё хранилище.

КАкой главный недостаток этой схемы -- народ не хочет работать над фризом. По многим причинам. По причинам того, что это не их дело. Единственное, что может завестись здесь дополнительное хранилище под названием бэкпортс. Это тоже недостаток, в какой-то момент их никто не хочет суппортить. Главные недостаток -- лазить сюда неохота.

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

  1. автоматизация тестов по контролю анметов.
  2. предположим мы решили бороться с анметами автоматическим путем. как? перестать принимать пакеты с анметами? нужна ещё полиси по тому, как вообще теперь поддерживается сборка нового пакета, если он ломает зависмости.

Итак, сборка не прошла, что дальше? Нужно упростить процесс пересборки. Мы можем надеяться на то, что в хранилище нельзя будет помещать пакеты без того, чтобы разработчики пересобиралли свои пакты стала былью.

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

Знаете как ещё бороться с анметами -- давайте пересоберм пакет с другим именем, который провайдит нужную функциональность. В комьюнити с строгим полиси так и делают.

Чем плохо? У вас будет много версий одной и той же библиотеки.

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

Ввести полтитку кто когда может пересобирать.

Ввести понятие груповой сборки.

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

получается замкнутая по сборке группА, которая пока целиком не собрется, в хранилище не добавляется.

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

Это хорошо, а не плохо. У дебиана есть такая проблема -- добрая половина пакетов болтается в неизменном виде лет пять. Вопрос -- а они нужны? А никто не знает.

Группа сборки.

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

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

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

Не админимстратор сборочницы управляет сборкой, а майнтейнер.

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

Пусть есть пакет, он принадлежит пользователю эврибади -- любой человек может пересобрать. Жопустим их двое, каждый модифицировал пакет, не зная ничего о том, что другой делает тоже самое и послали на сборку. Первый пакет собрался, а второй нет. Как сборочница узнала о том, что второй пакет не надо собирать после первого?

Был пакет фууу.1.2.3.аль1, а собрали фууу.1.2.3.альт2. Второму откажут. Обиженный пользователь два соберет пакет альт3 и все имзменения сделанные первым пользователем пропадут. Мы не можем надеяться, что номер версии определяет старшинство пакетов. Должен быть механизм определения наследования --- когда собираем версию пакета, должно быть написано, что мы собрали из старого. С давних пор в сизифе есть проверка на ченджлог.

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

LecturesCMC/PackageMaintaining2013/Conspects/07 (последним исправлял пользователь Allena 2013-04-20 17:32:23)