PspoClasses/080720/01Repository

Сообщество вокруг дистрибутива

Чуть ранее был блок, посвященный сообществу, и было сказано о сообществе не вокруг одного конкретной свободной программы, а вокруг дистрибутива. Аналогия достаточно прямая, есть разделение на ядро, разработчиков и пользователей и в том, и в другом случае. В сообществе вокруг дистрибутива в роли разработчиков выступают сопровождающие (мейнтейнеры, от англ. maintainer), роль разработчика остается, потому что они обеспечивают этой структуре стабильность. В случае организации бизнеса на основании свободного ПО, у нас есть ресурс (средний слой -- разработчики), который выполняет роль "бесплатных разработчиков", в нашем проекте участвуют все, кому это интересно и кто может себе помочь в развитии этого проекта. Пользователи у нас — это такие "бесплатные тестеры" (опять же, это неправильно сказано, так обычно говорят наши оппоненты: вот у вас есть бесплатные разработчики, которые кое-как все делают, и тестируете вы на пользователях. На самом деле картина другая, она становится более очевидной, когда мы говорим, что есть информационная связность, и главное — это не только наличие этих самых людей, но и активное участие в информационном пространстве. Тогда пользователи уже не подопытные кролики, а в первую очередь заказчики. К тому же, совершенно не понятно, почему разработчики должны работать хуже, чем ядро, они работают иногда даже лучше, например, человек может быть слишком высоким профессионалом в своей узкой области, чтобы все своё время посвящать нашему проекту, но иногда принимает в нем участие, за что ему большое спасибо.)

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

Так вот, по отношению к дистрибутиву у core team сохраняются все те же функции, что и по отношению к обычной свободной программе, а понятие разработчика слегка размывается, т.к. основной фигурой на этом месте становится мейнтейнер, он же сопровождающий. Это человек, который имеет некоторую необходимость использовать программный продукт в рамках нашего дистрибутива, и эта необходимость настолько сильная, что он готов сам заниматься сборкой этого продукта, т.е. превращением из исходного кода в бинарный, и адаптацией его под конкретные условия, под дисциплину сборки программных продуктов, принятую в нашем дистрибутиве. Более того. в действительности дистрибутив — это конечный продукт некоей технологии, которая в качестве базового элемента имеет не дистрибутив, а то что называется хранилищем (англ. repository).

Хранилище

С точки зрения человека, не знакомого с этой технологией, хранилище выглядит просто как свалка, набор программных продуктов, адаптированных для работы в конкретном дистрибутиве. Набор достаточно внушительный, в хранилище ALTLinux их порядка 9 тысяч. Если приглядеться, в хранилище есть несколько дополнительных свойств, которые делают его не просто FTP-сайтом со складом файлов. Во-первых, файлы, которые помещаются в хранилище, помещаются туда мейнтейнерами пакетов.

Мейнтейнеры

Человек, который вдруг решил, что ему необходимо использовать некий программный продукт, который до этого не был адаптирован к некоторому дистрибутиву, может этот продукт скачать с сайта производителя, собрать из исходников бинарный пакет, и поместить результат работы в хранилище, пользуясь правами члена сообщества. Не всякий человек может туда положить пакет, а только тот, который, условно говоря, сдал экзамен на право называться разработчиком. Ничего такого в этом экзамене нет, человек просто должен показать, что он может в принципе такие вещи делать. Вот, допустим, в Debian GNU/Linux правила приёма сложнее, человек иногда не может годами туда попасть. Дело в том, что Debian --- это сообщество, которое полностью базируется на дисциплине. Там нет оплачиваемых людей, зарплату получают только администраторы сборочных серверов, больше никто, поэтому такие вещи там очень важны, если какой-то член core team против включения кого-то в состав разработчиков, значит есть тому резон.

Дисциплина оформления пакетов

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

То есть

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

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

Далее, предполагается, что если мейнтейнер поместил пакет в хранилище, то он

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

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

Тут стоит заметить, что процедура сборки — превращения исходного текста в бинарный, результирующий программный продукт в изолированном окружении, в нашем хранилище Сизиф из известных во всем мире наиболее продвинутая и технологичная. В Debian все устроено примерно так же, но есть некие тонкие различия. Что касается других дистрибутивов, то там пожиже. Это достаточно непростой процесс, могу отослать к статьям Димы Левина про технологию сборки Сизиф и про hasher — инструмент, который позволяет организовывать изолированное окружение и сборку.

ftp://ftp.altlinux.org/pub/people/ldv/hasher/index.html

http://freesource.info/wiki/AltLinux/Dokumentacija/Hasher?v=vsm&search=hasher

Зависимости между пакетами. Обновления и стабильность

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

Хранилище Сизиф именно в связи с этим небезопасно для повседневного использования. Допустим, сопровождающий пакета, gtk (популярная интерфейсная библиотека графической среды, используемая многими программными продуктами), принимает решение, что новая версия gtk, со всякими изменениями внутри, очень хороша, и кладет ее в хранилище. Что при этом происходит? Все программные продукты, которые требуют библиотеку gtk, становятся нерабочими. Потому что библиотека новая, программы старые, собраны с предыдущей версией библиотеки, которой уже нет, вместо неё есть новая версия, а старая удалилась. Попытка воспользоваться этим множеством пакетов при таком состоянии хранилища, приведет к тому, что библиотека эта обновится, а все другие пакеты, от неё зависящие, удалятся на вашей машине, потому что у них есть неудовлетворённая зависимость. Это немедленно заметит сообщество, особенно те люди, которые используют Сизиф в качестве повседневного программного окружения, и за мейнтейнером gtk потянутся мейнтейнеры других программных продуктов, которые используют gtk, пересобирать свои программные продукты с поддержкой новой версии gtk. В какой-то момент ситуация вокруг gtk стабилизируется, потому что те мейнтейнеры, которым это интересно, поднимут свои версии, а те, которым это неинтересно и которых мы давно не встречали на просторах интернета, про это дело забудут, а программы останутся неработоспособными. Но если мейнтейнера у программы нет, практически это значит, что её никто не использует. Сизиф — это такое вечно нестабильно хранилище всего, и название как нельзя лучше отражает суть работы: вот ты значит старался-старался, компилировал-компилировал, исправлял причудливую мысль автора этой программы, наконец, все ошибки исправил, выложил в Сизиф, получил обратную связь от пользователей, ещё раз какие-то ошибки исправил, а через два дня вышла новая версия этой программы. Значит, камень скатывается обратно и все начинается сначала.

Заморозка. Стабильные ветки

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

Дистрибутивы

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

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

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

backports

Есть еще одно ответвление в этом технологическом процессе. Пусть есть хранилище, которое объявлено стабильным — ветка. В нем запрещается делать обновления, за исключением обновлений по безопасности и исправлений грубых ошибок. Что если мы хотим, пользуясь программным окружением этого стабильного хранилища, воспользоваться суперновой программой, которой либо вообще во времена стабилизации ветки в ней не было, либо со времён стабилизации она серьёзно обновилась? Болезнь новых версий у всех есть, даже у тех осторожных людей, которые не пользуются Сизифом, а пользуются дистрибутивами. Для них есть отдельное небольшое хранилище, которые поддерживается таким же сообществом больных новыми версиями, которое называется backports. Берутся пакеты из Сизифа и пересобираются в окружении ветки. Предполагается, что такого рода пересборка проходит (а бывает, что нет, допустим нужна более свежая версия компилятора), предполагается что использование пакетов из backports не портит стабильности ветки, хотя это никто не гарантирует. В любом случае, это намного лучше, чем пытаться одновременно брать пакеты со стабильной ветки и из Сизифа.

Относительно объёмов — хранилище содержит около 9000 пакетов. Типичный дистрибутив на DVD — порядка 4000 пакетов, на CD — порядка 800. Двухслойный DVD — 8000-9000 пакетов.

Посмотрим репозиторий

lftp ftp.altlinux.org

lftp ftp.altlinux.org:/pub> ls
lrwxrwxrwx    1 ftp      ftp            30 Jun 15  2007 Mozilla -> distributions/ALTLinux/Mozilla
lrwxrwxrwx    1 ftp      ftp            33 Jun 15  2007 OpenOffice -> distributions/ALTLinux/OpenOffice
drwxr-sr-x   10 ftp      ftp          4096 Jul 24 12:49 beta
drwxr-xr-x    6 ftp      ftp          4096 Aug 01  2006 distributions
drwxr-xr-x    5 ftp      ftp          4096 Apr 02  2006 docs
drwxrwsr-t    3 ftp      ftp          4096 Jun 10  2006 mirrors
drwxr-sr-x    5 ftp      ftp          4096 Mar 11  2003 partners
drwxr-xr-x   72 ftp      ftp          4096 Jul 09 14:51 people
drwxr-xr-x    3 ftp      ftp          4096 Jun 25  2004 security

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

lftp ftp.altlinux.org:/pub/distributions> ls
drwxr-xr-x   13 ftp      ftp          4096 Jul 30 21:49 ALTLinux
drwxr-xr-x    3 ftp      ftp          4096 Feb 21  2006 FreeMusic
drwxr-xr-x    3 ftp      ftp          4096 Feb 21  2006 OpenMusic
drwxr-xr-x    3 ftp      ftp          4096 Jun 15  2007 archive

Это по именам дистрибутивов.

lftp ftp.altlinux.org:/pub/distributions/ALTLinux> ls
drwxr-xr-x    3 ftp      ftp          4096 Feb 13  2003 2.2
drwxr-xr-x    4 ftp      ftp          4096 Jul 01  2004 2.3
drwxr-xr-x    3 ftp      ftp          4096 Nov 03  2004 2.4
drwxr-xr-x   10 ftp      ftp          4096 Mar 03  2006 3.0
drwxr-xr-x    7 ftp      ftp          4096 Jun 05 20:14 4.0
drwxr-xr-x    3 ftp      ftp          4096 May 07 00:12 4.1
drwxrwsr-x    4 ftp      ftp          4096 May 31  2007 Daedalus
drwxr-xr-x   14 ftp      ftp          4096 Aug 01 07:09 Sisyphus
drwxrwsr-x    8 ftp      ftp          4096 May 12 09:57 backports
drwxr-xr-x    5 ftp      ftp          4096 Jul 30 21:37 old
drwxr-xr-x    9 ftp      ftp          4096 Dec 09  2007 updates

• Sisyphus — это хранилище Сизиф,

• 2.2, 2.3, ..., 4.1 — это стабильные ветки, сделанные в своё время.

• backports — это backports (внутри — по веткам)

• updates — обновления к веткам и дистрибутивам (по отдельности, т.к. одно и то же может обновляться по-разному из-за особенностей допилки в дистрибутивах)

Сведения о ресурсах

• CategoryLectures CategoryPspo CategoryMpgu CategoryUneex