[devel] Угрозы развитию дистрибутива. Пути решения.

[Igor Vlasenko <vlasenko@imath.kiev.ua>]

Уважаемые коллеги,

хочу поделиться в devel@ своим проектом 
доклада на OSDN-2011 в Киеве, так как тема касается проблем 
развития дистрибутива, и, думаю, будет всем интересна.
Прошу читать и комментировать.

----------------------------------------
<текст доклада>
----------------------------------------

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

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

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

Это аналог теории Томаса Мальтуса применительно к дистрибутивам.

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

Master2.2  1780
Master2.4  3226
Compact3.0 4569
branch4.0  6871
branch5.1  9758
Sisyphus  12390

Количество майнтайнеров за это время колебалось в районе 100+ человек.

Пессемистический сценарий вполне возможен. Например,
во времена так и не оформленного в дистрибутив бранча 5.0
были нехорошие тенденции такого рода с протуханием пакетов 
и оттоком майнтайнеров и пользователей.
Тогда ALT Linux справился с ними, и благополучно здравствует.

Но проблема "большее число пакетов требует большего числа ресурсов"
никуда не делась. 

Итак, что же ждет нас в будущем?

<картинка1.jpg>
Death Star is approaching the planet Yavin. 
субтитры:
The rebel base is on the moon on a far side.
The moon with the rebel base will be in range in 30 minutes...
</картинка>

Что же делать, чтобы эта проблема не "выстрелила" в 
критический момент?

Первое - это снижать затраты ресурсов на сопровождение.

Как пример,
Когда-то сборка и пересборка исходного пакета была достаточно сложным 
и кропотливым занятием, отнимавшим заметную долю времени при
сопровождении пакета. Сейчас эти задачи автоматизированы настолько,
что субъективно воспринимаются как атомарные операции.
Репозиторий СПО ``Sisyphus'' может заслуженно гордиться, наверное,
лучшей в своем классе системой сборки hasher, а также своим
автоматизированным incoming.

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

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

Пример: робот обновления пакетов perl.
интересная вещь: робот, который может самостоятельно
обновлять пакеты по cron,
снимая с майнтайнера 90% времени на работы. Оставшиеся
10% -- это разборки с пакетами, для которых у робота возникли проблемы
(не хватило зависимостей, отвалился патч, и т.д.).
Его можно развернуть в песочнице и управлять  через acl.

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

<картинка2.jpg>
/Luke in the fighter, hearing Obivan's voice/
субтитры:
Luke! Use the Source!
Remember, the Source will be with you. Always.
</картинка>


Вернемся к истокам.
Спросим себя. "В чем сила, брат?".

Наша сила в Open Source. Пользуясь Open Source, продвинутый пользователь
Вася Пупкин за 20 минут может изготовить для своей супруги Маши
персональный офисный пакет, который при запуске поздравит Машу с днем
рождения, и ему для этого не нужны будут миллионы долларов и десятки
лет разработки.
 
Проблема "большее число пакетов требует большего числа ресурсов"
проявляет себя потому, что разные дистрибутивы вынужденно дублируют
усилия друг друга.
С этой же проблемой связана и мечта об универсальном пакете.

Универсальный пакет - пакет, который можно собрать и установить в
почти любой дистрибутив. Мечта о универсальном пакете появилась вместе
с первыми дистрибутивами. 
Почему упаковщики пакетов дублируют усилия друг друга, ведь пакеты это Open Source?
Почему не смог родиться универсальный пакет?

Напрашивающийся вывод - сохранять совместимость похоронил 
не одну сотню дистрибутивов-форков. Иногда эта стратегия работает, в основном
для нишевых дистрибутивов и небольших изменений.
Возвращаясь к примеру с продвинутым пользователем Васей Пупкиным,
можно взять дистрибутив, поменять обои и выпустить диск с "Pupkin Live! (tm)".
Но когда приходится поддерживать особенности, которые по каким-то
причинам в базовый дистрибутив не принимаются (например, устаревшие
особенности ранее вышедшего дистрибутива), то возникают проблемы.

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

Но почему это так?
и почему упаковщики пакетов дублируют усилия друг друга? 

= Дистрибутивы как диалекты.

Свободное программное обеспечение в целом характеризуется большой
гибкостью и широкими возможностями адаптации и повторного
использования. Для задач совместной распределенной разработки
программного обеспечения создано большое число различных
инструментальных средств. Эти  инструментальные средства сохраняют
свою высокую эффективность при распределенной работе над пакетами в
рамках одного репозитария, но резко снижают свою эффективность при
пересечении границ дистрибутивов. К примеру, выполнение инструкций
сборки для исходных пакетов одной и той же программы, например, в
Debian и ALT Linux, может давать полностью пофайлово идентичные
бинарные пакеты; при этом, если, скажем, в пакет для  Debian будут
впоследствии внесены некоторые полезные изменения, то эти изменения,
скорее всего, не заведомо не получится перенести в исходный пакет той
же программы, но предназначенный для одного из репозиториев  ALT Linux
с помощью стандартных утилит diff (1) и patch (1). 

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

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

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

Вспомним, какой толчок в разработке ядра Linux произошел 
при переезде на распределенную систему управления версиями.

Как уже говорилась, логика diff (1) и patch (1)
плохо работает при пересечении границ дистрибутивов.
Какие же инструменты нужны?

= Конвертирование пакетов как альтернатива универсальному пакету.

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

Конечно, конверсия тоже далеко не бесплатна, но сопровождать один конвертер
гораздо, гораздо, гораздо дешевле, чем 5-10 тысяч пакетов, которые он
может сопровождать.

Конвертировать можно 
* из других дистрибутивов; 
* из специализированных репозиториев вроде CPAN, HackageDB, Ruby Gems, PyPI;
Конвертируя, можно получить в итоге 
"В Греции есть все", "One ring rule them all" дистрибутив.

В конверсии сила открытого программного обеспечения проявляет себя полностью.

Как это работает на практике?

В рамках разработки системы автоматизированного импорта и
сопровождения программных пакетов srpmimport ведется разработка
прототипа программного комплекса автоматизации портирования и
сопровождения программных пакетов из репозитория СПО «fedora» в
нестабильной ветки репозитория СПО «Sisyphus» fcimport.

Среди других успешных опытов по автоматизации сопровождения исходных
пакетов надо назвать проекты autoports, cronbuild, CPAN update,
а также их сопутствующую инфраструктуру.
Проект autoports во время испытательного срока собрал более 2000
пакетов для репозитория 5.1.
В рамках проекта fcimport сейчас сопровождается более 700 пакетов
репозитория СПО ``Sisyphus'', при чем это только тестовое множество,
используемое при разработке fcimport.
В рамках проекта JPPimport сейчас сопровождается более 1000 java пакетов
репозитория СПО ``Sisyphus''.

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

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

= Аспектно-ориентированное сопровождение пакетов.

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

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

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

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

Тот же подход можно применить и при сопровождении конвертируемых или
параллельно сопровождаемых пакетов.

Опишем необходимые нам изменения в виде "аспекта", т.е. выпишем 
наши изменения как набор инструкций на языке редактирования пакетов.
Это позволяет автоматизировать задачу повторного внесения изменений.

srpmimport использует реализацию языка редактирования пакетов в
библиотеке RPM::Source::Editor языка perl.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.