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

[Michael Pozhidaev <msp@altlinux.ru>]

Игорь, добрый день!

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

В нашем понятии "пакет" сильно затруднена процедура автоматического
тестирования. Результат работы "робота" непредсказуем. В части пакетов
она могла бы быть возможна, в другой части возможна, но при содействии
мейнтейнера. Фактически, мы ничего не знаем о состоянии пакетов в
Сизифе. 

Как логическое довершение к материалу Вашей статьи, мне кажется, можно
было бы обсудить возможные варианты автоматического тестирования
состояния пакета. Тестирование - это чуть ли не обязательный этап
разработки ПО, с которым у нас как-то, почему-то, дело не сложилось.

Мои две копейки. :))

> Уважаемые коллеги,
>
> хочу поделиться в 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

-- 
Michael Pozhidaev. Tomsk, Russia.
Russian info page: http://www.marigostra.ru/