Журнал LinuxFormat - перейти на главную

LXF147:Fedora

Материал из Linuxformat
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

Внутри Fedora

Составление дистрибутива – задача чрезвычайно сложная. Джонатан Робертс ведет нас за кулисы Fedora, чтобы мы увидели, как это происходит.


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

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

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

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

В нашей статье мы проведем вас за кулисы Fedora и совершим прогулку от ранних стадий планирования и разработки до внесения финальных битов.

Важно отметить, что такого внимания заслуживает не только Fedora: существует огромное количество проектов свободного ПО, чудесных с инженерной и логистической точки зрения. И данной статьей мы затеваем новую серию – мы ежемесячно будем заглядывать за кулисы разных дистрибутивов или проектов.

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

Еще до планирования или разработки конкретных деталей каждый релиз начинает свою жизнь в «rawhide [сыромятной]» ветке Fedora. Это полноценная версия дистрибутива, но она никогда не выходит официально, а, напротив, существует в непрерывной стадии перемешивания: постоянно добавляются новые пакеты, а старые, будь они важными или побочными, обновляются до свежих версий; вводятся новые функции, а устаревшие ликвидируются.

Результат предсказуем: rawhide-версия не является стабильной. Иногда ее можно установить, но и это не гарантируется; также нет уверенности, что можно загрузиться и безопасно использовать систему, составленную из пакетов этой ветки Fedora.

Вместо этого, ее цель– снабдить разработчиков полигоном, где они начинают понимать, какой эффект на остальную часть дистрибутива произведет то или иное обновление; и именно там обновления становятся доступными другим разработчикам для тестирования пакетов и программ.

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


Коллекция пакетов

Во-первых, вам нужно знать, что Fedora – это дистрибутив, основанный на RPM, то есть по сути это коллекция «пакетов» – скомпилированных двоичных файлов, укомплектованных с дополнительными «метаданными» (данными о данных), чтобы помочь компьютеру автоматически отслеживать, какие файлы содержатся в пакете и каким программам они принадлежат. Благодаря этому установку, обновление и удаление пакетов через менеджер пакетов производить очень легко.

Вообще говоря, RPM бывают двух типов: RPM исходников (SRPM) и стандартные RPM. Первые отличаются тем, что содержат не двоичные файлы, а исходные файлы программ, а также дополнительные заплатки и набор инструкций для компиляции исходного кода в стандартный RPM.

Именно так все пакеты Fedora, и все функции Fedora, начинают свою жизнь: разработчики пишут «файл спецификации» и прилагают его к исходному коду, а затем запускают программу, создающую легко устанавливаемый RPM. После того, как пакет написания и скомпилирован, первой задачей Fedora Project становится внести его в управляемую систему для отслеживания изменений. Для этого нужен git.

Каждый пакет в Fedora – по крайней мере, RPM исходников (SRPM) – хранится в собственном git-репозитории. Если кто-нибудь добавляет новый пакет или обновляет старый, он должен создать новый репозиторий или «передать» обновление старому.

Для тех, кто не знает, сообщим, что git – это распределенная система контроля версий [distributed revision control system]. Вкратце, это небольшая программа, которая отслеживает различные версии («ветки») других программ.

В Fedora git-репозиторий каждого пакета обычно содержит одну ветку для каждой доступной на данный момент версии дистрибутива. Так как rawhide – тоже версия Fedora, самую последнюю версию каждого пакета всегда можно найти в ветке rawhide его git-репозитория.

Итак, rawhide начинает свою жизнь как набор git-репозиториев, каждый из которых содержит ветку «rawhide» с самыми последними SRPM. Не каждый может отправлять файлы в эти репозитории – чтобы получить разрешение, нужно иметь рекомендацию и успешно пройти процедуру рассмотрения; однако тем, кто заработал это право, предоставляют значительную свободу, о чем говорит тот факт, что rawhide постоянно меняется и обновляется.

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

Чтобы привести rawhide в более удобное состояние, Fedora Project полагается на две специальные утилиты.


Koji и Mash

Первая из них – «система сборки», известная в Fedora как Koji. Она используется для создания из мешанины исходного кода, спецификаций пакета и заплат, хранящейся в git, легко устанавливаемых – но не обновляемых автоматически – файлов RPM.

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

Koji, поступает по уму и создает окружение chroot – виртуальную файловую систему, для гарантии, что пакет собран с версиями важных пакетов, доступными в той версии Fedora, для которой пакет готовится.

Итак, Fedora Project запускает Koji со всеми файлами в «rawhide»-ветках своих проектов, создавая набор легко устанавливаемых RPM. Мы еще не пришли к rawhide, так как у нас пока не предусмотрен простой способ отслеживать и извлекать изменения.

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

Репозиторий также содержит файл boot.iso; с его помощью можно запустить виртуальный компьютер, скачать требуемые файлы и установить их на реальном компьютере.

И – вуаля! Rawhide готов! Чтобы добраться до этого места, уже проделано много работы, однако до конечного продукта – стабильной, надежной операционной системы для каждодневного использования – еще далеко. Все это происходит за время шестимесячного цикла релизов Fedora Project, и начинается с двухэтапного процесса планирования.

Сначала команда Release Engineering устанавливает расписание для преобразования rawhide в очередной стабильный релиз, содержащее несколько ключевых пунктов, включая заморозку функций [feature freeze] и ветки [branch freeze], а также альфа- и бета-релизы.

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


Блистательные функции

В другой аспект процесса планирования вовлечен комитет Fedora Engineering Steering Committee (FESCo), определяющий, какие «функции» войдут в каждый релиз. Согласно Робену Бержеро [Robyn Bergero], программному руководителю Fedora, все функции разделяются на две обширные категории: «новые и яркие» и те, от которых зависит «критический путь» – основные компоненты, влияющие на множество других пакетов и пользователей.

Первые дают пользователям представление о новых функциях, которые появятся после обновления. Вторые зачастую включают новые пакеты, устанавливаемые по умолчанию или заменяющие старые пакеты; изменения такого типа нелегко выполнить правильно, а если они пойдут не в ту сторону, то эффект от этого затронет многих. Отслеживая их как функции, три главные инженерные команды Fedora (FESCo, Release Engineering и Quality Assurance) могут пристально наблюдать за прогрессом, проверяя, что их амбиции реалистичны, что все довольны и что на случай провала имеются резервные планы.

Несмотря на столь всестороннее планирование, Fedora остается очень меритократичным проектом. Новую функцию может предложить каждый, и каждый может внести пакет в дистрибутив. Последнее слово остается за FESCo, но его состав на 100 % выбирается сообществом. Вот что сказал о политике введения новых обновлений в Fedora нынешний председатель FESCo Кевин Фенци [Kevin Fenzi]: «Мы должны прислушиваться ко всему и преобразовывать в то, что все мы считаем верным».

После принятия решения, какие функции войдут в релиз, разработчикам даются первые два месяца цикла на работу над rawhide. После этого проект входит в стадию заморозки «ветки» и «заявленных функций», когда для каждого отдельного пакета создается новая ветка, и контроль над репозиториями переходит от Mash к другой программе, под названием Bodhi.

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

Это важно для перехода Fedora от хаотической смеси к стабильности, пригодной для каждодневного использования.

Альфа, бета... выйди вон

После этого проект выпускает два предрелиза (альфа и бета); оба содержат все запланированные функции и распространяются в виде установочных DVD или live CD. Для их создания используются более специальные утилиты, соответственно Pungi и Live CD Creator, и перед выходом релиза созывается собрание трех основных команд разработчиков, убеждающееся, что соблюден минимальный набор стандартов.

И снова, идея таких предрелизов – затребовать дальнейшую обратную связь от максимального числа пользователей, чтобы финальный продукт был стабилен и полон самых свежих и лучших усилий разработчиков за последние шесть месяцев. Они особенно удобны, так как предоставляют общую платформу, на которой команда QA строит свои тестовые дни. Это значительные события в сообществе: разработчики функций и опытные инженеры заходят в Internet Relay Chat (IRC), чтобы провести пользователей через серию испытаний на их системах. В каждый день тестирования внимание уделяется функции или другому критическому компоненту, что позволяет получить большое число откликов.

Это дает Fedora возможность протестировать и отработать новые функции на максимально широком спектре оборудования, и представляет пользователям, менее продвинутым технически, отличные шансы посильно помочь разработке. Все, что для этого требуется – копия самого последнего предрелиза и доступ к IRC, а разработчики протащат вас через остальное.

Интересно, но якобы самое большое испытание для этих релизов – распространение гигабайтов данных по всему свету – является простейшей частью операции. Команда Release Engineering собирает все пакеты из той версии репозитория, что была успешно скомпилирована в носитель с установкой, а затем просто задает права на коллекцию такими, чтобы она не была доступна из внешнего мира.

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

Колдовства здесь нет: все зеркала просто используют rsync для создания своих копий главного зеркала Fedora. Когда все это сделано и настает день релиза, на всех зеркалах просто меняют права доступа («опрокидывают биты»), чтобы открыть его всем – и процесс скачивания пошел!

В итоге Fedora Project ухитряется из хаотической смеси пакетов, содержащих самый свежий код, изготовить тщательно протестированную, крепко сбитую коллекцию и в несколько приемов доставить ее по всему свету. Остается только составить носитель для окончательного релиза, который называется релизом GA (General Availability – общедоступным), и поставить его на зеркала тем же способом, что применялся для альфа- и бета-релизов.

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

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF147:Fedora&oldid=15370»
Персональные инструменты
купить
подписаться
Яндекс.Метрика