2sash-kan: Новая страница: «==Внутри Fedora== : Составление дистрибутива – задача чрезвычайно сложная. '''Джонатан Робер…»

2014-07-15T13:55:50Z

Новая страница: «==Внутри Fedora== : Составление дистрибутива – задача чрезвычайно сложная. '''Джонатан Робер…»

Новая страница

==Внутри Fedora==

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

{{Врезка|right|Заголовок=Открыта нараспашку|Содержание=В нашей статье мы обсудим по крайней мере полдюжины различных утилит, применяемых командой Fedora для компиляции релизов. Все они – открытое ПО, и таковыми же являются подробные документы, описывающие, как Fedora вводит их в дело.

Это значит, что каждый может скачать и изучить их, и узнать, как с помощью утилит и процедур промышленного масштаба создать собственную коллекцию пакетов, дополняющую Fedora, или даже собственный дистрибутив, основанный на RPM. Утилиты Fedora делают эту возможность далеко не теоретической: репозитории RPM Fusion и Extra Packages for Enterprise Linux (EPEL) применяют все эти средства, предоставляя пользователям те пакеты, что Fedora и Red Hat Enterprise Linux не могут или не хотят предоставлять.

Такая открытость, не только в пакетах, но и в утилитах и процедурах, является одним из основополагающих качеств Fedora и привлекла к проекту множество людей. Дэн Гилмор [Dan Gilmore], нынешний лидер команды Release Engineering, прежде чем стать куратором системы сборки, помогал команде Fedora Infrastructure, а потом ушел в Red Hat. Несмотря на то, что это теперь его штатная должность, в результате всесторонней и открытой природы средств, предоставляемых Fedora, он, по его словам, все еще чувствует «радость и гордость от своего участия».|Ширина=20%}}

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

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

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

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

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

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

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

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

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

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

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

{{Врезка|left|Заголовок=FUDCon|Содержание=Хотя многим не нравится тесная связь Fedora со своим коммерческим спонсором Red Hat, но она определенно имеет свои преимущества. Одно из них – у компании есть средства на проведение регулярных, по-настоящему международных конференций. Их называют Fedora User and Developer Conferences (FUDCon), и это прекрасный способ скоординировать новые возможности, накропать множество кода и выпить много пива.

Что здорово в FUDCon – это то, что они проводятся по всему свету: регулярные события происходят в Латинской Америке, Северной Америке и в Европе. В этом году также были выделены деньги на проведение FUDCon в Азиатско-Тихоокеанском регионе, так что явление становится поистине глобальным.|Ширина=20%}}

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

Во-первых, вам нужно знать, что 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 полагается на две специальные утилиты.

{{Врезка|right|Заголовок=Герои инфраструктуры Fedora|Содержание=Вы, наверное, заметили, что многие из утилит Fedora – web-службы, предоставляющие централизованное хранение и мощности, чтобы обеспечить выполнение работ по проекту, распределенному глобально между многими разрабочиками.

Без этих серверов и утилит, размещенных на этих серверах, не было бы и проекта Fedora. То есть обеспечение стабильности и безопасности – не просто сложная задача, но и жизненно важная.

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

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

Этот способ доказал свою эффективность, и администраторы – как добровольцы, так и от Red Hat – рассеяны по всему свету. Раньше все было неформально – люди просто встревали в почтовые рассылки и спрашивали, как они могут помочь; сейчас, однако, проект формализован по схеме Infrastructure Apprentice. Это прекрасный способ изучить работу систем в реальном мире для студентов, и один из способов стать участником.|Ширина=20%}}

===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 в надежную стабильную систему.

{{Врезка|left|Заголовок=Больше, чем дистрибутив|Содержание=В данной статье основное внимание было уделено техническим процедурам, используемым при создании релиза дистрибутива Fedora.

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

Сюда входит арт-группа, а также команды документации, маркетинга, переводов и сайта; каждая из них дает тот или иной вклад в релиз.

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

Все эти команды пользуются во многом теми же утилитами, что и программисты, включая системы контроля версий, и вся работа проходит в открытом формате, чтобы каждый смог сделать свой вклад.|Ширина=20%}}

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

В другой аспект процесса планирования вовлечен комитет 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 – общедоступным), и поставить его на зеркала тем же способом, что применялся для альфа- и бета-релизов.

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

LXF147:Fedora - История изменений

2sash-kan: Новая страница: «==Внутри Fedora== : Составление дистрибутива – задача чрезвычайно сложная. '''Джонатан Робер…»