НПП: с чем пойдем сдаваться

    Комментарий команды R&D компании РОСА к проекту создания прототипов систем для Национальной программной платформы.

    Многие интересуются, с чем мы пойдем на сдачу и показывают на старые сборочные инструменты Мандривы. На самом деле, выигрыш ПингВином первого этапа НПП и, как следствие, пришедшая в R&D РОСы задача по предоставлению системы сборки дают нашей скромной команде повод продемонстрировать публике развиваемый в РОСе/Mandriva внутренний проект универсального билд-сервера ABF.

    Этот проект мы начали в России для реализации нашей давней идеи автоматизированного согласования зависимостей при пересборке пакетов. А именно, ABF работает так, что новые пакеты не проходят апрув (и не попадают в репозитории) пока не достигнута пересборка всех зависимых от них. Процедура согласованной пересборки позволяет в т.ч. обрабатывать кольцевые зависимости. Как результат – один раз достигнутые корректность и воспроизводимость сборки набора пакетов (а значит – дистрибутивов и любых программ для них) далее не нарушаются неосторожными действиями майнтейнеров (с чем идеологам ABF приходилось в своей предыдущей жизни часто сталкиваться при построении производных Федоры, а позднее и самой Мандривы). Если майнтейнер предлагает некачественный пакет, он немедленно и автоматически получит его обратно с указанием переделать.

    На взгляд системных архитекторов РОСы/Mandriva, continuous integration при построении дистрибутивов – это не сколько сам факт ежедневных сборок из пакетов разной степени свежести, как часто бывает, но в гораздо большей степени – уверенность билд-менеджера в том, что все пакеты в образе собраны без конфликтов друг с другом, и проверять это нужно в целом, а не только набором локально применяемых тестов. Нам кажется странной ситуация, когда нарушение пакетом сборки других пакетов обнаруживается в значительной степени случайно, вручную и запросы на пересборку размещаются вручную же в списке рассылки без гарантии какой-либо реакции. Это – прошлый век.

    Конструктивно ABF представляет собой расширяемое распределенное множество билд-клиентов (для разных платформ и архитектур), работающих с единым хранилищем кода и управляемых из единого диспетчера-балансировщика. Уже сейчас есть билд-клиенты для Mandriva и для ряда RH-производных, то есть единообразно собираются различные дистрибутивы. От приходящего в эту инфраструктуру разработчика платформы/дистрибутива требуется создать на основе нашего шаблона собственный сборочный бэкенд (используя фрагменты скриптов оригинальной процедуры сборки) и импортировать исходные коды в хранилище. То есть, собрать любой RPM-based дистрибутив – это дело техники. С Debian-based дистрибутивами создание бэкендов несколько сложнее, но достижимо и уже запланировано. А уж создание производных дистрибутивов и сборка одного приложения для нескольких платформ – все это перестает быть хоть сколько-нибудь сложным.

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

    Вопрос о том, в каком режиме вести проект после сдачи для нас остается открытым. Безусловно, мы заинтересованы развивать его и приглашать дистрибутивные команды, особенно работающие с Debian-дистрибутивами, производными Мандривы (особенно будем рады глубокоуважаемой команде EduMandriva), а также собирающие дистрибутивы на других аппаратных архитектурах.

    Евгений Соколов
    ROSA R&D
    • –9
    • 2,6k
    • 3
    ПингВин Софтвер
    15,00
    Компания
    Поделиться публикацией

    Комментарии 3

      +6
      Как на счет отформатировать текст?
      Глаза в кучку от такого.
        0
        Уровень, на который мы претендуем – это уровень Launchpad и OBS.
        Важное свойство Launchpad — открытость для сообщества. Любой может там зарегистрироваться и создать PPA. Насколько я понимаю, то же и с OBS (хотя лично я использовал только MeeGoвый). Есть ли такая возможность у вас или система ориентирована исключительно на сборку вашего дистрибутива?

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

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

          Самое читаемое