Репозиторий СПО

Репозиторий свободного программного обеспечения.

Подходы к разработке инфраструктуры репозитория свободного программного обеспечения со сборочной средой.

Термины и определения.

Общее значение термина «репозиторий» в контексте информационных систем — актуализируемое хранилище электронных данных. Границы термина очень широки, и при желании «репозиторием» может быть названа любая систематизированная база данных. Однако на практике совпадения в употреблении терминов «база данных» и «репозиторий» не так часты. Под «базами данных» в основном понимаются хранилища, основанные на использовании одной из современных систем управления базами данных (СУБД) и являющиеся чаще компонентами более сложных систем, нежели самостоятельными системами. В то же время, «репозиторий» представляет самостоятельную программную систему, основой которой не обязательно является СУБД, но работа которой подразумевает регулярную актуализацию данных, с одной стороны, и предоставление их вовне — с другой.

Однако в практике организации разработки программного обеспечения (и уже — в практике разработки свободного программного обеспечения) термин «репозиторий» имеет несколько достаточно четко отделимых друг от друга контекстов употребления.

В первом случае «репозиторий» — это хранилище файлов, предназначенное для организации совместной работы программистов по созданию какой-либо программы. Использование репозитория позволяет программистам придать процессу коллективной работы организованный характер. С помощью репозитория ведется учет того, кем и когда внесены изменения в хранящиеся файлы, репозиторий позволяет определить, в чем именно заключались эти изменения, а в случае необходимости — возвратить файлы в исходное состояние. Известные средства организации репозиториев этого рода (также называемые «средства контроля версий») — CVS, Subversion, Git и др.

Во втором случае под «репозиторием» понимается веб-портал, совмещающий в себе функции каталога ПО, инструмента для организации сообществ по разработке ПО, среды информационного обмена для разработчиков, технической инфраструктуры разработки проектов по созданию ПО и инструмента для загрузки разработанного ПО («репозиторий-портал»). Такие порталы могут быть использованы при создании разных видов ПО, но наибольшую популярность приобрели именно в связи с проектами по созданию свободных программ. Примеры таких репозиториев — SourceForge.net, Google Code, Tigris.org, GNU Savannah.

В третьем случае под «репозиторием» понимается каталог программного обеспечения, направленный на конечных пользователей ПО, который может выступать как хранилищем файлов, так и хранилищем ссылок на другие сайты, где можно загрузить сооветствующие файлы («репозиторий-каталог»). Известными репозиториями такого рода являются CNET Download.com, Tucows.com, СОФТ@Mail.ru.

Наконец, в последнем случае речь идет о репозитории как об инфраструктуре разработки операционных систем, включающих, помимо системного ПО, любые программы пользовательского и серверного назначения («репозиторий пакетов»). Основная задача репозиториев этого рода — интеграция разных пакетов программ в единую систему. Объектом хранения в таких репозиториях выступают пакеты программ, где каждое наименование ПО (будь то ядро операционной системы, служебная библиотека, текстовый редактор, сервер для обслуживания электронных сообщений или медиа-проигрыватель) представлено в виде отдельного пакета. Наиболее известными репозиториями этого рода являются проекты ведущих компаний по разработке ПО с открытыми исходными кодами: Fedora (поддерживается компанией RedHat), OpenSuSE (компания Novell), Cooker (Mandriva), Debian, в России — ALT Linux Sisyphus.

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

Потребность в создании репозитория пакетов.

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

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

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

Процесс установки программного обеспечения сторонних производителей также существенно усложнился. За то время, пока создавались прикладные программы, производители операционных систем успевали внести обновления в системные файлы и для успешного исполнения устанавливаемого ПО приходилось перезаписывать некоторые системные библиотеки, что в свою очередь, приводило к неработоспособности отдельных компонентов, или операционной системы в целом. Возникла проблема «ада» или «кошмара» зависимостей (анг. Dependency hell). Проблема конфликта зависимостей специфичны для конкретной операционной платформы. Например, на операционных системах семейства Windows частично эта проблема была решена путем создания системного реестра, а впоследствии путем широкого внедрения технологии .NET. Однако и сегодня недостаточно квалифицированный разработчик может создать серьезные проблемы целостности операционной системы Windows при установке недостаточно проработанных компонентов.

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

На начальных этапах своего развития в операционной системе GNU/Linux использовался традиционный для unix-подобных систем способ установки программного обеспечения. Учитывая, что исходные тексты программ были доступны, прикладное ПО собиралось на каждой машине, что решало проблему конфликта зависимостей в значительной степени. Однако подобный способ распространения ПО требовал высокого уровня подготовки пользователей. Практически каждому персональному компьютеру требовался квалифицированный системный администратор, что существенно снижало широту применения подобных решений. Выход был найден путем распространения ПО в бинарном виде. Программное обеспечение собиралось на компьютере разработчика и могло быть установлено достаточно просто. Вот здесь и возникла проблема «кошмара зависимостей», существенно усугубляющаяся тем, что unix-подобные системы традиционно содержат гораздо большее количество мелких программных модулей и общее количество зависимостей существенно выше, чем, к примеру, у операционных систем семейства Windows. Отсутствие единого центра разработки, наличие множества независимых решений также осложняло и без того не простую ситуацию.

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

Система управления программными пакетами

В основе современных систем управления программным обеспечением для GNU/Linux и некоторых других unix-подобных операционных систем лежит концепция программного пакета.

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

Программные пакеты разделяют на:

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

Исходные пакеты. Содержат исходные тексты программ, которые можно модифицировать и собирать из них бинарные пакеты.

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

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

Обычно к метаданным относят:

• Название – собственное имя пакета;
• Версия – текущая версия содержимого пакета;
• Релиз – это номер ревизии пакета (при одной и той же версии программного обеспечения, может быть несколько версий сборки, чаще всего с исправленными ошибками);
• Упаковщик – указывается имя и адрес электронной почты человека, создавшего пакет;
• Зависимости – это ключевая концепция пакетной системы, в этом поле указывается, какие пакеты и каких версий необходимы данному пакету для работы. Указание зависимостей исключает установку программы при отсутствии необходимых внешних модулей;
• Предоставляет — описано, какие именно пакеты заменяет данный пакет;
• Размер – это суммарный размер всех файлов данного пакета после распаковки;
• Информация о месте и времени сборки;
• Краткое описание – описания пакета одной строкой;
• Подробное описание – обычно 10-20 строк, описывающий данный пакет;
• Журнал изменений – краткое текстовое описание изменений пакета от релиза к релизу;
• Группа – Указание типа программного обеспечения, к которому относится данный пакет (например «системные библиотеки», «прикладные программы», «графические редакторы» и т.п.)
• Лицензия – указано, под какой лицензией распространяется содержимое пакета;
• Исходный пакет – пакет из которого был собран данный бинарный пакет.

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

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

В процессе обработки программного пакета реализуются следующие транзакционные принципы:

Неделимость: Пакет не может быть «установлен наполовину»

Согласованность: Пакеты (как правило) не могут пересекаться по файлам или конфликтовать по зависимостям

Изоляция: В принципе, ничто не мешает ставить два независимых пакета одновременно

Устойчивость: Изменения вносятся в систему немедленно; отменить завершённую установку пакета невозможно, можно лишь удалить пакет (отдельной транзакцией)‏

К пакету применимо понятие целостности:

Наличие файлов: Можно проверить, все ли файлы из данного пакета на месте

Подлинность файлов: Можно узнать, какие файлы не соответствуют исходным.

Обработка транзакций по установке и удалению программных пакетов осуществляется с помощью специального программного обеспечения, именуемого системой управления пакетами (или менеджера пакетов, анг. package management system).

Наиболее популярной системой управления пакетами для платформы GNU/Linux является менеджер пакетов RPM.

RPM (Red Hat Package Manager — менеджер пакетов Red Hat или RPM Package Manager — RPM — менеджер пакетов) обозначает как формат пакетов программного обеспечения, так и программу для управления этими пакетами. Программа позволяет создавать, устанавливать, настраивать, удалять и обновлять программное обеспечение. Формат RPM является стандартом LSB (Linux Standard Base).

Изначально разрабатываясь компанией Red Hat для Red Hat Linux, RPM стал использоваться во многих дистрибутивах GNU/Linux и был портирован на другие операционные системы: Novell NetWare (с версии 6.5 SP3), IBM AIX (с версии 5) и прочие.

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

Каждый пакет RPM имеет название, которое состоит из нескольких частей:

• Название программы
• Версия программы
• Номер релиза
• Архитектура, под которую собран пакет (i586, x86_64 и т. д.)

Собранный пакет обычно имеет такой формат названия:

<название>-<версия>-<релиз>.<архитектура>.rpm

Например:

nano-2.2.4-alt1.i586.rpm

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

При всех своих достоинствах, менеджер RPM имеет один существенный недостаток — он не в состоянии отслеживать зависимости автоматически, а может только сообщить пользователю, каких именно пакетов не хватает для нормального функционирования устанавливаемой программы. В соответствии с модульными принципами создания приложений, принятыми в unix-подобных системах, разработчики не стали усиливать функциональность собственно RPM, а стали создавать инструментальные средства, работающие на более высоком уровне, как бы «поверх» RPM, вызывая его для непосредственного управления пакетами и реализующими недостающую функциональность.

Первым инструментальным комплектом, работающим поверх менеджера пакетов, был набор средств Advanced Packaging Tool, или APT; разработанный программистами проекта Debian для использования с менеджером dpkg.

Сотрудники бразильской компании Conectiva адаптировали данный комплект, оказавшийся весьма удачным, для работы «поверх» менеджера RPM. Большую работу, направленную на совершенствование APT и улучшение его взаимодействия с RPM, проделали сотрудники компании ALT Linux и участники ALT Linux Team.

APT и репозиторий пакетов.

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

В качестве такого источника используется репозиторий пакетов (анг. software repository или сокращенно repo). Собственно термин репозиторий дословно переводится, как «хранилище» и широко используется в компьютерной терминологии в самых разных значениях. Следует отличать репозиторий пакетов от других трактовок данного термина во избежание терминологической путаницы.

Под репозиторием пакетов понимается множество исходных пакетов, множество собранных из них бинарных пакетов, и мета-информация об этих пакетах.

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

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

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

Различают два вида замкнутости:

Замкнутость по установке. Попытка установить все бинарные пакеты не обнаружит неудовлетворенных зависимостей.

Замкнутость по сборке. Возможность полностью пересобрать репозиторий из собственных исходных пакетов.

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

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

Например, для обновления практически всего программного обеспечения (за исключением ядра ОС) на локальном компьютере до новой версии необходимо выполнить одну команду:

apt-get dist-upgrade

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

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

Репозитории пакетов.

Репозитории довольно давно используются в проектах по разработке свободных операционных систем, из которых наиболее известны Debian и Fedora (технологическая основа операционных систем Red Hat Linux). Debian и Fedora используют различные инструменты управления пакетами программ и учета межпрограммных зависимостей, позволяющие, в общем, с сопоставимой степенью эффективности решать задачи установки и обновления ПО, а также обеспечивать отсутствие неудовлетворенных зависимостей и не совместимых друг с другом наименований ПО.

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

Репозитории в государственном и муниципальном секторе

Наибольшее распространение получили репозитории, созданные в испанских провинциях Эстремадура и Андалусия, правительства которых содействовали появлению местных дистрибутивов Linux GNU/LinEx и Guadalinex, адаптированных к потребностям пользователей этих провинций. Обе системы используют в качестве базового репозиторий пакетов Debian.

Кроме Эстремадуры и Андалусии, аналогичные проекты были инициированы местными властями Мадрида и правительством провинции Кастилия Ла-Манча. В обоих случаях в качестве базового репозитория выбран Ubuntu. Аналогичный проект на основе Debian существует и в провинции Галисия, а в провинции Валенсия создан проект по созданию локализованного дистрибутива Linux на основе Edubuntu, версии Ubuntu, предназначенной специально для использования в учреждениях образования.

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

Однако в большинстве случаев принципиальных ограничений для использования свободных ОС за пределами школ не существует. Например, после того как дистрибутив GNU/LinEx показал свою успешность в учреждениях образования, он начал широко внедряться и в других учреждениях государственного сектора. Успех этого проекта послужил основным мотивом для создания аналогичных проектов в других испанских провинциях.

В Испании опыт создания суб-репозиториев для создания локализованных версий свободных ОС наиболее богат, однако аналогичные проекты существуют и в других странах. Самый известный — проект Limux, инициированный муниципальными властями Мюнхена в Германии и призванный предоставить необходимую инфраструктуру для миграции 14000 компьютеров города на свободное ПО. Большой интерес представляет индийский проект BOSS (Bharat Operating System Solutions), который осуществляется под эгидой Министерства информационных технологий Индии. В основе BOSS также лежит Debian, а основное внимание разработчики системы уделяют вопросам локализации системы с целью поддержки многочисленных местных языков Индии. Разработчики BOSS создали собственный репозиторий, в котором большая часть пакетов, тем не менее, заимствуется из Debian.

Репозиторий Sisyphus.

Как уже упоминалось выше, в настоящее время в мире существует несколько десятков репозиториев пакетов для различных дистрибутивов операционной системы GNU/Linux. Четвертым по количеству поддерживаемых пакетов является репозиторий Sisyphus.

Разработку и поддержку Sisyphus ведет независимая команда разработчиков ALT Linux Team, в которую входит более 150 участников из пяти стран мира, на его основе целый ряд независимых фирм строит самостоятельные коммерческие решения. Участие в Sisyphus открыто для всех желающих.

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

Свободное программное обеспечение разрабатывается по всему миру. Как правило, исходный программный код не предназначен для хранения в репозитории, в нем неизбежно могут содержаться ошибки, зачастую программа не имеет русской версии интерфейса и системы помощи. Перед помещением в репозиторий программа должна быть проверена на работоспособность и адаптирована к окружению репозитория. Данная работа требует значительных кропотливых усилий большого числа программистов. Поэтому на первом этапе создания Sisyphus необходимо было создать многочисленную команду единомышленников, обеспечить распределение полномочий в команде, разработать и воплотить в жизнь основные организационные принципы. Следовало учитывать, что большинство участников работает в команде в свое свободное время без материального поощрения, а значит, необходимо было найти стимулы для общекомандной деятельности. С момента своего создания визитной карточкой ALT Linux Team стали высокие профессиональные требования, предъявляемые к участникам проекта, надежность и кропотливость в работе. Особое внимание уделялось и уделяется качеству русификации всех программных продуктов.

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

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

В настоящее время в репозитории Sisyphus поддерживается свыше 12300 пакетов, содержащих лучшие свободные программы различной направленности:

• Базовая система
• Архивирование
• Базы Данных
• Безопасность
• Документация
• Доступность
• Графика
• Графические оболочки
• Игры
• Интерпретаторы команд
• Издательство
• Коммуникации
• Мониторинг
• Науки
• Обучение
• Офис
• Работа с файлами
• Работа с текстами
• Разработка
• Развлечения
• Редакторы
• Сети
• Система
• Терминалы
• Видео
• Звук
• Эмуляторы

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

В настоящее время на основе репозитория Sisyphus выпускается целое семейство дистрибутивов для применения в различных областях. Следует отметить, что все дистрибутивные комплекты ПСПО построены на пакетной базе и с помощью технологий репозитория Sisyphus.

Технологические решения, лежащие в основе Sisyphus.

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

RPM (менеджер пакетов). Мощный неинтерактивный менеджер пакетов, используемый для просмотра, сборки, установки, инспекции, проверки, обновления и удаления отдельных программных пакетов. Каждый такой пакет состоит из набора файлов и информации о пакете, включающей название, версию, описание пакета, и т.д. Отличительными особенностями RPM в Sisyphus являются: удобное поведение «по умолчанию» для уменьшения количества шаблонного кода в .spec-файлах, обширный модульный набор макросов для упаковки различных типов пакетов, развитые механизмы автоматического вычисления межпакетных зависимостей при сборке пакетов, поддержка set-версий в зависимостях на разделяемые библиотеки, автоматическое создание пакетов с отладочной информацией с поддержкой зависимостей между такими пакетами.

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

Git (распределенная система управления версиями). Представляет собой набор инструментов, разработанный для эффективного управления как очень большими проектами (такими как ядро linux), так и для личных нужд. Отличается высокой скоростью и масштабируемостью.

Кроме того, членами ALT Linux Team разработаны оригинальные технологии:

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

Gear – набор инструментов для поддержки совместной разработки RPM-пакетов в системе контроля версий git. Интегрирован с hasher, позволяет с помощью одного файла с простыми правилами безопасным и воспроизводимым образом собирать пакеты из произвольно устроенного git-репозитория. Не имеет аналогов, предназначенных для сборки RPM-пакетов.

Girar – система хостинга git-репозиториев, первоначально разработанная для упрощения совместной разработки в рамках ALT Linux Team. Отличается безопасной эффективной реализацией, простотой в использовании, и удобной интеграцией со сборочной системой girar-builder.

Girar-builder – cборочная система, интегрированная c системой хранения girar. первоначально разработанная для обслуживания репозитория Sisyphus. Построена по принципу автоматической обработки заданий-транзакций на обновление пакетов в репозитории. Использует hasher и gear для обеспечения безопасной воспроизводимой высокопроизводительной сборки бинарных пакетов из исходных пакетов и git-репозиториев. Реализует широкий спектр тестов, в том числе уникальных, для контроля за неухудшением различных характеристик репозитория.

Alterator - платформа для управления конфигурацией Linux-системы. На данный момент используется как инсталлятор и конфигуратор системы.

ALT Linux Installer - инсталлятор, используемый в дистрибутивах ALT Linux). Сделан на платформе Alterator, что делает его очень оригинальным и открывает широкие возможности.

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

Хранение исходного текста программ в системе контроля версий.

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

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

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

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

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

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

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

Первые попытки решения проблемы конфликтов при редактировании привели к созданию систем вида RCS, в которой для разрешения конфликтов использовались блокировки: разработчик, желающий исправить группу файлов, «получал их себе» (check out), вносил изменения и «возвращал» (check in) файл обратно.

Такой подход годился для небольших проектов, в которых разработчики не часто работали вместе над одним и тем же файлом. При росте количества разработчиков такой механизм начинал давать сбои -- становилось очень сложно найти момент, когда все необходимые для работы файлы были «на месте» для того, чтобы их получить. К примеру, в ядре Linux порядка 20 тысяч файлов, над которыми работает порядка 2 тысяч разработчиков. Поскольку многие изменения требуют внесения изменений в десятки файлов, и могут занять достаточно большое время, при применении блокировок разработка ядра превращалась бы в игру по ловле нужных файлов в их «возвращённом» состоянии. Изменения, затрагивающие большое количество файлов сразу (к примеру, исправление синтаксиса какой-то базовой функции, используемой во всей программе), были бы невозможны вовсе.

Эта проблема привела к появлению более гибкого подхода: каждый разработчик в проекте мог работать над любым файлом, но при внесении изменений в репозиторий должен был удостовериться, что вносимые изменения согласованы с главной копией. Для этого были разработаны программы, умеющие сливать (merge) изменения. сделанные разработчиками параллельно. Типичными примерами таких систем контроля версий являются CVS и Subversion.

Клиент-серверные системы контроля версий доминировали в течение 80-ых и 90-ых годов на рынке, но постепенный рост объёмов исходного кода, а также распространение Интернета и распределённой модели разработки показал их два существенных недостатка:

• любые операции для работы с историей требуют подключения к серверу,
• небольшое количество информации в рабочей копии разработчика требует передачи значительных объёмов данных по сети.

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

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

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

Ранние опыты в разработке распределённых систем контроля версий (GNU) Arch и Monotone работали достаточно медленно, но позволили накопить опыт для создания быстродействующих распределённых систем контроля версий, таких как Mercurial и git.

Git разрабатывался как система контроля версий для ядра Linux, но оказался крайне удобен для разработчиков дистрибутивов Linux.

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

Импорт из множества систем контроля версий. Использовать для разработки дистрибутива десятки или даже сотни систем контроля версий, которыми пользуются разработчики ПО, слишком сложно. Вместо этого для выбранной системы контроля версий должен существовать набор конвертеров для импорта истории из других систем контроля версий. Для git существует множество конвертеров из свободных и закрытых систем контроля версий. В частности, конверторы git-cvsimport и git-svn входят в стандартный набор инструментов git.

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

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

Изолированная сборочная среда.

Одной из отличительных особенностей технологических решений Sisyphus является использование изолированной сборочной среды для каждого собираемого пакета.

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

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

Поскольку все инструментальные средства установить в систему не удаётся, возникает необходимость прав администратора для установки произвольных требующихся для сборки пакетов в хост-систему.

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

И, наконец, при таком слабоконтролируемом составе сборочной среды, которой является хост-система, возникает неявная, не очевидная и нигде не обозначенная зависимость результата сборки от конкретной сборочной среды, возникают «неприкосновенные сборочные серверы».

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

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

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

Почему безопасности сборочной технологии уделяется так много внимания? Дело в том, что сборка дистрибутива является областью повышенного риска. С точки зрения потенциального нарушителя контроль над созданием пакетов и возможность внесения в них вредоносного кода крайне привлекательна, по мере распространения таких пакетов через них можно легко получить контроль над множеством серверов и рабочих станций. Большое число разработчиков разной квалификации приводит к тому, что некоторые из них могут стать лёгкой добычей для злоумышленников и впоследствии могут быть использованы для атаки на дистрибутив. Скомпрометированным может оказаться как клиентское ПО, используемое разработчиком, так и ПО, собираемое разработчиком. За последние годы были публичные случаи и того, и другого. Нельзя исключать и возможность непосредственной атаки на сборочную систему.

Таким образом, технология сборки пакетов репозитория должна:

• не снижать уровень безопасности хост-системы;
• обеспечивать собственную безопасность от атак со стороны пакетов;
• обеспечивать безопасность сборки пакетов от атак со стороны других пакетов;
• гарантировать надёжность (воспроизводимость) результатов сборки;
• обеспечивать приемлемый уровень производительности.

Для решения перечисленных задач участниками ALT Linux Team было разработано программное средство hasher, которое базируется на принципе создания новой сборочной среды для каждой сборки.

В основе архитектуры hasher'а лежит трёхпользовательская модель: вызывающий непривилегированный пользователь (C) и два непривилегированных вспомогательных псевдопользователя; первый (R) играет роль root в порождаемой сборочной среде, второй (U) - обычного пользователя, собирающего программы.

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

Путь пакета, проходящего через hasher, в общих чертах выглядит следующим образом:

1. Пользователь C порождает специальную среду (aptbox) для работы с apt.
2. Полностью удаляется сборочная среда, возможно оставшаяся от предыдущей сборки. Удаление происходит последовательно пользователем U, пользователем R и, наконец, пользователем C.
3. Пользователь C создаёт каркас новой сборочной среды, состоящий из вспомогательных каталогов и вспомогательных статически слинкованных программ (ash, find и cpio). С помощью вспомогательной привилегированной программы создаётся фиксированный набор файлов устройств, достаточный для нормального функционирования сборочной среды и при этом не несущий угроз host-системе.
4. Порождается базовая установочная среда, представляющая собой набор средств, необходимых для штатной установки пакетов в эту среду. Пользователь C с помощью aptbox определяет набор пакетов, необходимых для порождения базовой установочной среды. Пользователь R с помощью вспомогательных статически слинкованных программ распаковывает эти пакеты.
5. Порождается базовая сборочная среда, представляющая собой набор средств, необходимых для сборки любого пакета. Пользователь C с помощью aptbox определяет набор пакетов, пользователь R устанавливает их.
6. Пользователь U проверяет исходный пакет.
7. Порождается сборочная среда для данного пакета. Пользователь U извлекает сборочные зависимости пакета, пользователь C с помощью aptbox определяет набор пакетов для установки, и пользователь R устанавливает их.
8. Пользователь U осуществляет сборку пакета и проверку результатов сборки.

Все без исключения процессы пользователей R и U выполняются в сборочном чруте.

Такая схема призвана исключить атаки вида U->R, U->C, R->C, а также все виды атак на root. Для повышения производительности, особенно важной при сборке большого числа пакетов, применяется кэширование базовой сборочной среды, что позволяет сократить шаги 4 и 5 в схеме, приведенной выше, и тем самым свести к минимуму неизбежные накладные расходы на создание новой сборочной среды для каждой сборки. С помощью средств apt реализована возможность использования собранных ранее пакетов для сборки последующих пакетов.

Сборка пакетов из git-репозиториев исходного кода.

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

Для того, чтобы из произвольно устроенного git-репозитория можно было бы собирать пакеты, необходим инструмент, с помощью которого коммит, предназначенный для сборки, экспортировался бы из git-репозитория и преобразовывался к виду, пригодному для сборки. Для того, чтобы этот инструмент был бы удобен в использовании, правила такого преобразования должны быть достаточно простыми, а для того, чтобы это преобразование было безопасным, необходимо исключить использование инструментальных средств (таких как rpm-build), исполняющих произвольный код,

Решением этой задачи стал разработанный участниками ALT Linux Team набор инструментов gear для управления git-репозиториями исходного кода. Основная идея, заложенная в gear, заключается в том, чтобы с помощью одного файла с простыми правилами экспорта коммитов (для обработки которых достаточно sed и git) можно было бы безопасно собирать пакеты из произвольно устроенного git-репозитория, по аналогии с hasher, который был задуман как средство безопасно собирать бинарные пакеты из произвольных исходных пакетов.

Инструментарий gear реализует такие возможности, как

• экспорт коммитов в различных форматах;
• импорт исходных пакетов;
• обновление апстримного кода в репозитории;
• автоматизация написания changelog'ов;
• автоматизация изготовления подписанных тэгов;
• интеграция с RPM и hasher.

К языку правил экспорта коммитов предъявляется два естественных требования. С одной стороны, для того, чтобы исходный пакет мог быть импортирован в git-репозиторий наиболее удобным для пользователя способом, язык правил, согласно которым производится экспорт из коммита репозитория (в форму, из которой можно однозначно изготовить исходный пакет или запустить сборку), должен быть достаточно выразительным. С другой стороны, для того, чтобы можно было безбоязненно собирать пакеты из чужих git-репозиториев, этот язык правил должен быть достаточно простым.

Реализованные в gear правила экспорта коммитов удовлетворяют обоим этим требованиям. Файл правил экспорта (по умолчанию .gear/rules) состоит из строк формата

директива: параметры

параметры разделяются пробельными символами. Директивы позволяют экспортировать:

• любой файл из дерева, соответствующего коммиту;
• любой каталог из дерева, соответствующего коммиту в виде tar- или zip-архива;
• unified diff между любыми каталогами, соответствующими коммитам.

Файлы на выходе могут быть сжаты с помощью gzip, bzip2 или xz.

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

Правила экспорта и типовые шаблоны ведения gear-репозитория подробно описаны в документации по .gear/rules.

Хостинг git-репозиториев.

Система хостинга git-репозиториев girar первоначально была разработана для упрощения совместной разработки в рамках ALT Linux Team. Сейчас эта система решает следующие задачи:

• Управление git-репозиториями разработчиков. Каждый разработчик имеет собственные копии git-репозиториев, над которыми он работает и в которые только он может вносить изменения.
• Управление системой email-оповещений об изменениях в git-репозиториях, которая упрощает обмен изменениями. Каждый разработчик может выбрать для мониторинга интересующие его события в интересующих его git-репозиторияхhttp://www.altlinux.org/Git.alt/Справочник#email. При этом фактический обмен и аккумуляция изменений осуществляется средствами распределенной системы контроля версий git.
• Управление сборкой пакетов в репозитории пакетов из gear-репозиториев и SRPM-пакетов. Для сборки пакетов используется механизм заданий: пользователь указывает, какие gear-репозитории и SRPM-пакеты необходимо собрать одной транзакцией, создавая задание, после чего запускает его на выполнение. Каждое задание предназначено для изменения только одного репозитория пакетов. Задание обрабатываются сборочной системой girar-builder асинхронно. По завершению обработки задания пользователю приходит отчет по email, а результат обработки публикуется. Задания, по какой-либо причине забракованные сборочной системой, переводятся в отложенный режим, после чего они могут быть доработаны и отправлены на повторную сборку.
• Управление правами доступа к сборке пакетов в репозитории пакетов. Несмотря на то, что любой разработчик может внести изменения в исходный код любого пакета и отправить его на сборку, отправить собранный пакет в указанный репозиторий пакетов могут только те разработчики, за которыми закреплен этот пакет в этом репозитории.
• Публикация git-репозиториев. Разработчикам предоставляется доступ на чтение к git-репозиториям по протоколу ssh. Публичный доступ на чтение к git-репозиториям предоставляется по протоколам git, http, ftp и rsync. Авторизованным пользователям предоставляется доступ на чтение к git-репозиториям ограниченного доступа. Кроме того, с помощью gitweb реализован web-интерфейс просмотра git-репозиториев.
• Управление аккаунтами разработчиков. Администратору предоставляется командный интерфейс создания новых аккаунтов и изменения параметров уже существующих аккаунтов.

Система хостинга git-репозиториев girar состоит из следующих основных компонент:

• Структура каталогов файловой системы:
  • /people
    Каждому зарегистрированному разработчику предоставляется место для git-репозиториев, начинающееся с /people/$USERNAME. Доступ на запись в эти директории даётся только владельцу. Структура для хранения репозиториев жестко определена:
    • /people/$USERNAME/etc/
      Содержит git-репозитории packages.git, private.git, public.git, с помощью которых можно управлять подпиской на email-оповещения. Эти конфигурационные git-репозитории доступны только владельцу.
    • /people/$USERNAME/packages/
      Предназначен для хранения gear-репозиториев для репозиториев пакетов. Публично доступен. git-репозитории в этом каталоге просматриваются при выполнении команды find-package, и этот каталог используется по умолчанию в командах init-db, clone, build и task add repo.
    • /people/$USERNAME/private/
      Предназначен для хранения приватных репозиториев, о существовании и содержании которых должно быть известно только самому разработчику.
    • /people/$USERNAME/public/
      Предназначен для хранения публичных git-репозиториев, не являющихся gear-репозиториями для репозиториев пакетов.
  • /gears/
    В этот каталог помещаются gear-репозитории с исходным кодом репозиториев пакетов. Добавление исходного кода в репозиторий /gears происходит по окончании успешной сборки задания, Каждый gear-репозиторий в /gears назван по имени пакета с исходным кодом. Бранчи в нем называются по имени репозитория пакетов, в которую собрался пакет.
  • /srpms/
    В этом каталоге размещаются gear-репозитории с исходным кодом пакетов, собранных из SRPM-пакетов. Добавление исходного кода в репозиторий /srpms происходит по окончании успешной сборки задания путем автоматического импорта SRPM-пакета утилитой gear-srpmimport.
  • /tasks/
    Здесь размещается структура каталогов сборочных заданий.
• Система управления git-репозиториями разработчиков, состоящая из следующих основных инструментов:
  • создание нового git-репозитория;
  • клонирование git-репозитория, в т.ч. из внешнего источника;
  • удаление git-репозитория;
  • перемещение и переименование git-репозитория;
  • обновление данных в git-репозитории с помощью git-receive-pack;
  • извлечение данных из git-репозитория с помощью git-send-pack;
  • получение списка git-репозиториев;
  • поиск git-репозитория по шаблону имени;
  • получение и изменение бранча по умолчанию;
  • получение и изменение параметров упаковки git-репозитория;
  • получение информации об использованной и доступной дисковой квоте.
• Система автоматической рассылки email-оповещений об изменениях в git-репозиториях разработчиков. По окончании обновления каждого такого git-репозитория автоматически формируется оповещение, содержащее, в частности, список изменений, описание изменений и ссылку на обновленный коммит или тэг. Это оповещение с помощью почтовой службы postfix отправляется по email всем подписчикам данного типа изменений в обрабатываемом git-репозитории.
• Система подписки на рассылки email-оповещений.
  Реализовано два вида почтовой подписки на события:
  • Разработчик подписывается на события, происходящие в git-репозиториях типа packages и public.
  • Разработчик подписывает кого-то на события, происходящие в его репозиториях типа packages, public или private.Для подписки используются репозитории packages.git, public.git и private.git из каталога /people/$USERNAME/etc/. Схема работы с подписками напоминает работу с CVSROOT из CVS: пользователь клонирует нужный репозиторий, коммитит изменения в него и push-ит обратно на сервер, после чего изменения вступают в силу. Формат этих конфигурационных репозиториев подробно описан в справочном руководстве по girar.
• Система автоматической публикации git-репозиториев по протоколам ssh, git, http, ftp и rsync. Каждый из этих протоколов обслуживается отдельной службой. Каждая из этих служб может быть активирована и деактивирована независимо от остальных служб.
• Web-интерфейс просмотра git-репозиториев gitweb дает возможность просматривать дерево каталогов и содержимое файлов для любого коммита, просматривать log и shortlog любого бранча, изучать коммиты, их описания и вносимые ими изменения. Gitweb поддерживает генерирование RSS-лент, экспорт снапшота дерева каталогов для любого коммита, а также поиск по git-репозиторию.
• Система управления доступом к сборке пакетов в репозитории пакетов, состоящая из следующих основных инструментов:
  • просмотр прав доступа на сборку указанного пакета в указанный репозиторий пакетов;
  • проверка прав доступа на сборку указанного пакета в указанный репозиторий пакетов пользователем, осуществляющим эту проверку;
  • изменение прав доступа на сборку указанного пакета в указанный репозиторий пакетов; этот инструмент доступен только ответственному за этот пакет в этом репозитории пакетов, а также администраторам этого репозитория пакетов;
  • создание новых и удаление существующих записей о правах доступа на сборку указанного пакета в указанный репозиторий пакетов; этот инструмент доступен только администраторам этого репозитория пакетов.
  • автоматическая рассылка email-оповещений об изменениях в правах доступа на сборку пакетов в репозитории пакетов.
• Система управления сборочными заданиями, состоящая из следующих основных инструментов:
  • мониторинг очереди заданий путем получения списка заданий, удовлетворяющих заданным критериям;
  • детальный просмотр указанного задания;
  • создание нового задания для указанного репозитория пакетов;
  • удаление задания;
  • добавление в задание подзадания на сборку тэга из gear-репозитория;
  • добавление в задание подзадания на сборку SRPM-пакета;
  • добавление в задание подзадания на копирование пакета из другого репозитория пакетов;
  • добавление в задание подзадания на удаление пакета из репозитория пакетов;
  • удаление подзадания из указанного задания;
  • одобрение указанного подзадания в чужом задании;
  • отправка задания в очередь на сборку в репозиторий пакетов;
  • отправка задания в очередь на сборку без обновления репозитория пакетоа; в случае успешной сборки такое задание станет персональным дополнением к репозиторию пакетов.
• Ssh-интерфейс к следующим системам:
  • управления git-репозиториями;
  • подписки на рассылки email-оповещений;
  • управления доступом к сборке пакетов;
  • управления сборочными заданиями.
• Web-интерфейс к системе управления сборочными заданиями.
• Система управления аккаунтами, состоящая из следующих основных инструментов:

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

Сборочная система.

Cборочная система Girar-builder, интегрированная c системой хранения girar. первоначально была разработана для обслуживания репозитория Sisyphus. Эта система построена по принципу автоматической обработки заданий-транзакций на обновление пакетов в репозитории пакетов. Когда новая сборка пакета окончательно подготовлена, разработчик делает в gear-репозитории подписанный тэг (или подписывает SRPM-пакет) и с помощью girar создает задание на сборку пакета. Если задание было обработано успешно, то собранные пакеты помещаются в репозиторий пакетов, а gear-репозиторий с новым тэгом публикуется в каталоге кэширующих gear-репозиториев /gears/ (в случае сборки SRPM-пакета – в каталоге /srpms/). Названия кэширующих gear-репозиториев в этих каталогах совпадают с именами SRPM-пакетов (это требование не является обязательным для gear-репозиториев разработчиков). Таким образом, каталоги кэширующих gear-репозиториев /gears/ и /srpms/ предоставляют доступ к официально опубликованным gear-репозиториям, содержимое которых соответствует фактическим сборкам пакетов.

Каждое задание состоит из одного или нескольких gear-репозиториев (и тэгов к ним) и/или SRPM-пакетов, отправленных на сборку. Сборочная система сначала осуществляет первичную сборку пакетов. Если при первичной сборке пакетов возникли грубые ошибки, то задание автоматически отменяется. В противном случае, если все пакеты в задании успешно собрались, то открывается транзакция: генерируется временный репозиторий, в котором выполняется ряд проверок (вычисляются характеристики нового репозитория). По умолчанию переход в новое состояние разрешён, только если характеристики репозитория не ухудшились. Если же собранные пакеты ухудшают характеристики репозитория, то составляется список нарушений, и задание переводится в отложенный режим.

Система автоматической обработки сборочных заданий girar-builder состоит из следующих основных компонент:

• Система распределения заданий по удаленным узлам.
• Конвейеры сборки и тестирования задания, развернутые на удаленных узлах, состоят из следующих основных этапов:
  • Изготовление временной копии целевого репозитория.
  • Подготовка подзаданий к сборке с помощью GEAR - инструмента безопасного, однозначного и эффективного извлечения указанного коммита из данного gear-репозитория в форме, предназначенной для сборки пакетов.
  • Параллельная сборка пакетов на удаленных узлах, возможно на различных аппаратных архитектурах, с помощью системы сборки пакетов hasher. Благодаря реализованной в hasher архитектуре обеспечивается:
    • безопасность узла, на котором производятся сборки;
    • безопасность и изолированность друг относительно друга нескольких сборок, производимых одновременно на одном узле;
    • воспроизводимость сборок;
    • высокая производительность сборок.По умолчанию, если иное не указано в спецификации исходного пакета, сборка производится для всех поддерживаемых аппаратных архитектур (например, на i586 и x86_64). По умолчанию, если иное не указано в исходном коде пакета, для каждого rpm-пакета, содержащего ELF-файлы, во время сборки автоматически создается debuginfo-пакет с отладочной информацией. Автоматически сгенерированные зависимости между debuginfo-пакетами обеспечивают установку всех пакетов, необходимых для отладки.
  • Первичное тестирование собранных пакетов на грубые ошибки, включающее в себя:
    • тестирование rpm-пакетов утилитой sisyphus_check;
    • проверку однократности сборки: пакет, собранный в одном подзадании, не должен быть собран в другом подзадании;
    • проверку упорядоченности версий: для каждого пакета тройка epoch:version-release должна быть больше, чем в целевом репозитории пакетов и предшествующих ему репозиториях пакетов, и меньше, чем в последующих репозиториях пакетов;
    • проверку соответствия имен релизов пакетов правилам: формат релиза каждого пакета должен соответствовать правилам, действующим репозитория пакетов;
    • идентичность noarch-пакетов: noarch-пакеты, собранные на разных архитектурах, должны быть идентичны по составу и зависимостям.
  • Вычисление нового состояния репозитория пакетов, состоящее из обновления и переиндексирования пакетов.
  • Тестирование нового состояния репозитория пакетов, включающее в себя:
    • зависимости между пакетами: в новом состоянии репозитория не должно быть новых неудовлетворенных зависимостей;
    • cсылки на ELF-символы: в новом состоянии репозитория не должно быть новых ссылок на неопределённые ELF-символы;
    • устанавливаемость пакетов: каждый из собранных бинарных пакетов должен успешно устанавливаться.
    • пересобираемость пакетов: все ранее собиравшиеся пакеты, не входящие в задание, у которых в вычисляемой hasher'ом индивидуальной сборочной среде присутствует хотя бы один из свежесобранных пакетов, должны успешно собираться.
  • Вторичное тестирование собранных пакетов, включающее в себя:
    • преемственность сборок: каждый исходный пакет должен базироваться на предыдущей сборке этого пакета, при сборке из gear-репозитория это означает наследование истории git-коммитов, а при сборке SRPM-пакета – наследование changelog'а;
    • проверка прав доступа: для каждого подзадания должно быть выполнено хотя бы одно из условий:
      • автору подзадания разрешено собирать пакет;
      • хотя бы одному из подтвердивших подзадание разрешено собирать пакет.Множество тестов, успешное прохождение которых обязательно для успешного выполнения задания, определяется конфигурацией репозитория пакетов, для обновления которого было сформировано это задание.
        Каждый репозиторий пакетов обслуживается одним или несколькими экземплярами конвейера сборки и тестирования, все экземпляры конвейеров работают независимо друг от друга.
        Подключение нового сборочного узла состоит в установке на него ПО сборочной системы и регистрации этого нового узла на управляющем узле.
• Конвейер реализации заданий, успешно обработанных одним из конвейеров сборки и тестирования, состоит из следующих основных этапов:
  • Обновление кэширующих git-репозиториев, которые создаются по одному на каждый исходный пакет, содержат тэги всех успешно собранных заданий, а также ссылки на текущие собранные тэги для каждого репозитория пакетов.
  • Обновление и публикация нового состояния репозитория пакетов.
  • Обновление базы данных прав доступа в случае добавления в репозиторий новых пакетов либо удаления из репозитория старых пакетов.Каждый репозиторий пакетов обслуживается одним экземпляром конвейера реализации, которые работают независимо друг от друга.
• Рассылка email-отчета по окончании обработки задания.
• Состояние сборочного задания публикуется по мере обработки по протоколу http.
• Задание, по тем или иным причинам отвергнутое сборочной системой, переводится в отложенный режим, после чего c помощью системы управления сборочными заданиями оно может быть доработано разработчиком и отправлено на повторную сборку.
• Журнал операций, в который вносятся записи обо всех изменениях состояния заданий по мере их обработки, позволяет администратору системы производить полный аудит событий в системе.

---