Различия между версиями 2 и 4 (по 2 версиям)
Версия 2 от 2008-08-02 15:33:15
Размер: 35633
Редактор: PavelSutyrin
Комментарий: расшифровано почти
Версия 4 от 2008-08-02 15:38:57
Размер: 35599
Редактор: PavelSutyrin
Комментарий: расшифровано
Удаления помечены так. Добавления помечены так.
Строка 1: Строка 1:
Администратор сам себя. перебираемся к курсу "Расширенный курс системного администрирования."  Администратор сам себя. перебираемся к курсу "Расширенный курс системного администрирования."
Строка 5: Строка 5:
Понятно, если человек не очень хорошо умеет управлять своим компьютером даже на уровне своих пользовательских потребностей, то в таком виде бросать человека нельзя.   Понятно, если человек не очень хорошо умеет управлять своим компьютером даже на уровне своих пользовательских потребностей, то в таком виде бросать человека нельзя.
Строка 7: Строка 7:
=== Сообщество вокруг дистрибутива ===  === Сообщество вокруг дистрибутива ===
Строка 9: Строка 9:
Чуть ранее был блок, посвященный сообществу, и была такая тема: сообщество вокруг дистрибутива программного продукта, не вокруг одного конкретного свободного ПО, а вокруг дистрибутива, я еще показывал, что аналогия достаточно прямая, есть разделение на ядро разработчиков и пользователей и в случае отдельного ПО, и в случае дистрибутива, во втором случае в роли разработчиков выступают сопровождающие, они же мейнтейнеры, роль разработчика никуда не девается, потому что они обеспечивают всему эту занятию стабильность (если бы мы тратили все ресурсы на поддержку core team и надеяться только на них, и приход был бы равен расходу, то ничем иным, кроме как торговать воздухом, т.е. лицензиями, мы бы не смогли, иначе бы мы просто прогорели. В случае организации бизнеса на основании свободного ПО, у нас такой вот ресурс (средний слой -- разработчики), который выполняет роль бесплатных разработчиков, в нашем проекте участвуют все, кому это интересно и кто может себе помочь в развитии этого проекта. Пользователи у нас -- это такие бесплатные тестеры (опять же, это неправильно сказано, так обычно говорят наши оппоненты: вот у вас есть бесплатные разработчики, которые кое-как все делают, а тестируете вы на пользователях, там есть другая картина, она становится более очевидной, когда мы говорим, что есть информационная связность, и главное -- это не только наличие этих самых людей, но и активное участие в информационном пространстве, тогда пользователи отнюдь не подопытные кролики, а в первую очередь заказчики, получается, что совершенно не понятно, почему разработчики должны работать хуже, чем ядро, они работают иногда даже лучше, просто человек слишком высокий профессионал, чтобы все свое время посвящать нашему проекту, но иногда принимает в нем участи, за что ему большое спасибо.)  Чуть ранее был блок, посвященный сообществу, и была такая тема: сообщество вокруг дистрибутива программного продукта, не вокруг одного конкретного свободного ПО, а вокруг дистрибутива, я еще показывал, что аналогия достаточно прямая, есть разделение на ядро разработчиков и пользователей и в случае отдельного ПО, и в случае дистрибутива, во втором случае в роли разработчиков выступают сопровождающие, они же мейнтейнеры, роль разработчика никуда не девается, потому что они обеспечивают всему эту занятию стабильность (если бы мы тратили все ресурсы на поддержку core team и надеяться только на них, и приход был бы равен расходу, то ничем иным, кроме как торговать воздухом, т.е. лицензиями, мы бы не смогли, иначе бы мы просто прогорели. В случае организации бизнеса на основании свободного ПО, у нас такой вот ресурс (средний слой -- разработчики), который выполняет роль бесплатных разработчиков, в нашем проекте участвуют все, кому это интересно и кто может себе помочь в развитии этого проекта. Пользователи у нас -- это такие бесплатные тестеры (опять же, это неправильно сказано, так обычно говорят наши оппоненты: вот у вас есть бесплатные разработчики, которые кое-как все делают, а тестируете вы на пользователях, там есть другая картина, она становится более очевидной, когда мы говорим, что есть информационная связность, и главное -- это не только наличие этих самых людей, но и активное участие в информационном пространстве, тогда пользователи отнюдь не подопытные кролики, а в первую очередь заказчики, получается, что совершенно не понятно, почему разработчики должны работать хуже, чем ядро, они работают иногда даже лучше, просто человек слишком высокий профессионал, чтобы все свое время посвящать нашему проекту, но иногда принимает в нем участи, за что ему большое спасибо.)
Строка 11: Строка 11:
В случае дистрибутивов роль core team -- определять стратегическое направление -- куда развивать дистрибутив, и не давать проявляться субъективным факторам как то ленивым разработчикам, ленивым или просто ушедшим на другую деятельность по ключевым направлениями, чтобы конкретное ключевое направление, допустим, веб-браузеры, чтобы веб-браузер был на уровне, и чтобы ядро ОС было достаточно защищено и современное, а то вот если вдруг какой-то сторонний человек, не входящий в core, вообще изредка участвующий в этом сообществе, с ленцой, вдруг получается так, что он занимается ключевой частью дистрибутива, не исключены ошибки: в ядре ОС давно ошибки, а оно все еще висит старое.   В случае дистрибутивов роль core team -- определять стратегическое направление -- куда развивать дистрибутив, и не давать проявляться субъективным факторам как то ленивым разработчикам, ленивым или просто ушедшим на другую деятельность по ключевым направлениями, чтобы конкретное ключевое направление, допустим, веб-браузеры, чтобы веб-браузер был на уровне, и чтобы ядро ОС было достаточно защищено и современное, а то вот если вдруг какой-то сторонний человек, не входящий в core, вообще изредка участвующий в этом сообществе, с ленцой, вдруг получается так, что он занимается ключевой частью дистрибутива, не исключены ошибки: в ядре ОС давно ошибки, а оно все еще висит старое.
Строка 13: Строка 13:
Так вот, по отношению к дистрибутиву у core team сохраняются все те же функции, что и по отношению к обычной свободной программе, а вот что касается понятия разработчика -- оно слегка размывается, т.к. основной ключевой фигурой по отношению к дистрибутиву становится мейнтейнер, он же сопровождающий. Это человек, который имеет некоторую необходимость использовать программный продукт в рамках нашего дистрибутива, и эта необходимость настолько сильная, что он готов сам заниматься сборкой этого продукта, т.е. превращением из исходного кода в бинарный, и адаптацией его под конкретные условия, под дисциплину сборки программных продуктов, принятую в нашем дистрибутиве. Более того. в действительности дистрибутив -- это конечный продукт некоей технологии, которая в качестве базового элемента имеет не дистрибутив, а то что называется хранилище.   Так вот, по отношению к дистрибутиву у core team сохраняются все те же функции, что и по отношению к обычной свободной программе, а вот что касается понятия разработчика -- оно слегка размывается, т.к. основной ключевой фигурой по отношению к дистрибутиву становится мейнтейнер, он же сопровождающий. Это человек, который имеет некоторую необходимость использовать программный продукт в рамках нашего дистрибутива, и эта необходимость настолько сильная, что он готов сам заниматься сборкой этого продукта, т.е. превращением из исходного кода в бинарный, и адаптацией его под конкретные условия, под дисциплину сборки программных продуктов, принятую в нашем дистрибутиве. Более того. в действительности дистрибутив -- это конечный продукт некоей технологии, которая в качестве базового элемента имеет не дистрибутив, а то что называется хранилище.
Строка 15: Строка 15:
=== Хранилище ===  === Хранилище ===
Строка 17: Строка 17:
С точки зрения человека, который вообще не в курсе, хранилище выглядит просто как свалка, набор программных продуктов, адаптированных для работы в конкретном дистрибутиве. Набор достаточно внушительный, в хранилище ALTLinux их порядка 9 тысяч, или больше. Если приглядеться, в хранилище есть несколько дополнительных свойств, которые делают его не просто FTP-сайтом со складом файлов. Во-первых, файлы, которые помещаются в хранилище, помещаются туда этими самыми мейнтейнерами пакетов.   С точки зрения человека, который вообще не в курсе, хранилище выглядит просто как свалка, набор программных продуктов, адаптированных для работы в конкретном дистрибутиве. Набор достаточно внушительный, в хранилище ALTLinux их порядка 9 тысяч, или больше. Если приглядеться, в хранилище есть несколько дополнительных свойств, которые делают его не просто FTP-сайтом со складом файлов. Во-первых, файлы, которые помещаются в хранилище, помещаются туда этими самыми мейнтейнерами пакетов.
Строка 19: Строка 19:
==== Мейнтейнеры ====  ==== Мейнтейнеры ====
Строка 21: Строка 21:
Человек, который вдруг решил, что ему необходимо использовать некий программный продукт, который до этого не был адаптирован к некоторому дистрибутиву, он этот продукт скачивает с сайта производителя, собирает их исходников бинарный продукт, и помещает результат работы в это самое хранилище, пользуясь правами члена сообщества. НЕ всякий человек может туда положить пакет, а только тот, который, условно говоря, сдал экзамен на право называться разработчиком. Ничего такого в этом экзамене нет, человек просто должен показать, что он может в принципе такие вещи делать. вот в Debian GNU/Linux правила приема сложнее, человек иногда не может годами туда попасть. Дело в том, что GNU Debian -- это сообщество, которое полностью базируется на дисциплине, там нет оплачиваемых людей, зарплату получают только администраторы сборочных серверов, больше никто, поэтому такие вещи очень важны, если какой-то член core team против включения кого-то в состав разработчиков, значит есть тому резон.   Человек, который вдруг решил, что ему необходимо использовать некий программный продукт, который до этого не был адаптирован к некоторому дистрибутиву, он этот продукт скачивает с сайта производителя, собирает их исходников бинарный продукт, и помещает результат работы в это самое хранилище, пользуясь правами члена сообщества. НЕ всякий человек может туда положить пакет, а только тот, который, условно говоря, сдал экзамен на право называться разработчиком. Ничего такого в этом экзамене нет, человек просто должен показать, что он может в принципе такие вещи делать. вот в Debian GNU/Linux правила приема сложнее, человек иногда не может годами туда попасть. Дело в том, что GNU Debian -- это сообщество, которое полностью базируется на дисциплине, там нет оплачиваемых людей, зарплату получают только администраторы сборочных серверов, больше никто, поэтому такие вещи очень важны, если какой-то член core team против включения кого-то в состав разработчиков, значит есть тому резон.
Строка 25: Строка 25:
В хранилище помещают исходный и собранный варианты программного продукта, адаптированного в местной дисциплине сборки, помещают не абы кто, а те самые мейнтейнеры. Пакет попадает в хранилище не сразу. Первым делом происходит проверка его на пригодность, на то, насколько правильно в нем соблюдена дисциплина сборки программных продуктов для хранилища (в случае Альт Линукс -- это Сизиф, и проверка называется sisyphus-check). Дисциплина оформления пакетов в Сизиф -- это подробная штука, существуют строгие рекомендации, что можно делать, а что нельзя, и фактические мейнтейнер закачивает в это хранилище не бинарный пакет, который он собрал руками, а адаптированный пакет с исходными текстами (исходный пакет), и специальный робот берет этот пакет, и не бия в бубен и не глядя по сторонам и тупо собирает его по тем правилам, которые внутри пакета заключены. Если по этим правилам пакет собирается, значит он, в числе прочего, соответствует дисциплине сборки пакетов. Если он не собирается, т.е. автоматом в изолированном окружении эти исходные тексты нельзя превратить в бинарный продукт, значит автор там у себя бил в какой-то непонятного диаметра бубен и такой пакет в хранилище не помещается.   В хранилище помещают исходный и собранный варианты программного продукта, адаптированного в местной дисциплине сборки, помещают не абы кто, а те самые мейнтейнеры. Пакет попадает в хранилище не сразу. Первым делом происходит проверка его на пригодность, на то, насколько правильно в нем соблюдена дисциплина сборки программных продуктов для хранилища (в случае Альт Линукс -- это Сизиф, и проверка называется sisyphus-check). Дисциплина оформления пакетов в Сизиф -- это подробная штука, существуют строгие рекомендации, что можно делать, а что нельзя, и фактические мейнтейнер закачивает в это хранилище не бинарный пакет, который он собрал руками, а адаптированный пакет с исходными текстами (исходный пакет), и специальный робот берет этот пакет, и не бия в бубен и не глядя по сторонам и тупо собирает его по тем правилам, которые внутри пакета заключены. Если по этим правилам пакет собирается, значит он, в числе прочего, соответствует дисциплине сборки пакетов. Если он не собирается, т.е. автоматом в изолированном окружении эти исходные тексты нельзя превратить в бинарный продукт, значит автор там у себя бил в какой-то непонятного диаметра бубен и такой пакет в хранилище не помещается.
Строка 27: Строка 27:
То есть 
  
  * проверяется формальное соответствие правилам оформления программных
продуктов для сизифа и
  * фактическая его собираемость в изолированном окружении.
  

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

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

Было бы неплохо, если бы где-то были какие-то правила по тестированию, чтобы вместе с программным продуктов приезжал некий набор тестов, на которых бы он запускался и еще и работал, но вот такого не происходит, просто потому что это не всегда легко организовать. Если кто работал в промышленном программировании, знает что система тестирования занимает процентов 50 от общего времени разработки, и если авторы этого не сделали, допустим, автор три года разрабатывал программный продукт, фактически, чтобы написать полную систему тестов, нужно еще три года. кто это будет делать. То есть если сразу они от автора не приезжают, то их и нет. Если он от автора приезжают, то до какой-то степени протестировать тоже можно.
Строка 38: Строка 37:
 * тот факт, что он им пользуется и не видит никаких ошибок, как раз и есть если не лучший, то весьма эффективный способ тестирования. В конце концов, мало ли какие роботы какие программы как тестируют, а тут человек с помощью программы что-то делает, работает, она у него работает, и он на этом основании помещает ее в хранилище, оно же ему нужно, вот оно это и делает.   * тот факт, что он им пользуется и не видит никаких ошибок, как раз и есть если не лучший, то весьма эффективный способ тестирования. В конце концов, мало ли какие роботы какие программы как тестируют, а тут человек с помощью программы что-то делает, работает, она у него работает, и он на этом основании помещает ее в хранилище, оно же ему нужно, вот оно это и делает.
Строка 40: Строка 39:
Тут стоит заметить, что процедура сборки -- превращения исходного текста в бинарный, результирующий программный продукт в изолированном окружении, в нашем хранилище Сизиф из известных во всем мире наиболее продвинутая и технологичная. В Debian все очень неплохо устроено, примерно также, но есть там некие тонкие различия. Что касается других дистрибутивов, то там пожиже. Это достаточно непростой процесс, могу отослать к статьям Димы Левина про технологию сборки Сизиф и про hasher (ссылки?) -- инструмент, который позволяет организовывать изолированное окружение и сборку.   Тут стоит заметить, что процедура сборки -- превращения исходного текста в бинарный, результирующий программный продукт в изолированном окружении, в нашем хранилище Сизиф из известных во всем мире наиболее продвинутая и технологичная. В Debian все очень неплохо устроено, примерно также, но есть там некие тонкие различия. Что касается других дистрибутивов, то там пожиже. Это достаточно непростой процесс, могу отослать к статьям Димы Левина про технологию сборки Сизиф и про hasher (ссылки?) -- инструмент, который позволяет организовывать изолированное окружение и сборку.
Строка 44: Строка 43:
В первый день лектор говорил, что сообщество вокруг дистрибутива предоставляет мейнтейнеру некоторые технологические преимущества, так вот это они и есть. Когда ты (мейнтейнер пакета), условно говоря, просто поместить во входную очередь для сборки некий программный продукт, предварительно его оформив как надо, он соберется, проверится, всякие хитрости, связанные с интеграцией его в общую среду этого хранилища проверится, и ты будешь гарантирован, что если ошибок не произошло, то ты никому не навредил, и значит, в следующий раз, когда ты свой же программный продукт себе же на компьютер поставишь, он не войдёт в конфликт с чем-то ещё.   В первый день лектор говорил, что сообщество вокруг дистрибутива предоставляет мейнтейнеру некоторые технологические преимущества, так вот это они и есть. Когда ты (мейнтейнер пакета), условно говоря, просто поместить во входную очередь для сборки некий программный продукт, предварительно его оформив как надо, он соберется, проверится, всякие хитрости, связанные с интеграцией его в общую среду этого хранилища проверится, и ты будешь гарантирован, что если ошибок не произошло, то ты никому не навредил, и значит, в следующий раз, когда ты свой же программный продукт себе же на компьютер поставишь, он не войдёт в конфликт с чем-то ещё.
Строка 46: Строка 45:
=== Зависимости между пакетами. Стабильность === === Зависимости между пакетами. Обновления и стабильность ===
Строка 48: Строка 47:
Мы в прошлый раз говорили про разделяемый библиотеки. Поскольку программные продукты в хранилище взаимодействуют друг с другом: например, программы, написанные для графической подсистемы, они пользуются целым большим множеством соответствующих программных инструментов, интерфейсной графической библиотекой, математической библиотекой (мы о ней говорили), утилитами какими-то, которые вызываются при работе программы. Каждый из этих элементов на самом деле является отдельным программным продуктом и лежит в хранилище отдельно от другого, отдельным пакетом.   Мы в прошлый раз говорили про разделяемый библиотеки. Поскольку программные продукты в хранилище взаимодействуют друг с другом: например, программы, написанные для графической подсистемы, они пользуются целым большим множеством соответствующих программных инструментов, интерфейсной графической библиотекой, математической библиотекой (мы о ней говорили), утилитами какими-то, которые вызываются при работе программы. Каждый из этих элементов на самом деле является отдельным программным продуктом и лежит в хранилище отдельно от другого, отдельным пакетом.
Строка 50: Строка 49:
Именно хранилище сизиф и именно в этом смысле небезопасно для повседневного использования. Понятно почему, допустим я, сопровождающий пакета, допустим, gtk (GIMP Toolkit, популярная интерфейсная библиотека графической среды, используемая многими программными продуктами), принимаю решение, что новая версия gtk, со всякими изменениями внутри, она очень хороша и я ее естественным образом у себя дома использую, и естественным образом кладу в хранилище. Что при этом происходит? Все программные продукты, которые требуют библиотеку gtk, становятся нерабочими. Потому что, библиотека новая, программные старые, собраны с предыдущей версией библиотеки, которой уже нет, вместо него я заложил новую версию, старая удалилась. Попытка воспользоваться вот этим множеством пакетов в текущем состоянии, с условием, что я туда положил новую библиотеку, приведет к тому, что библиотека эта обновится, а все другие пакеты, от нее зависящие, удалятся на вашей машине, поэтому у них есть неудовлетворенная зависимость. Это немедленно заметит сообщество, особенно те люди, которые используют сизиф в качестве повседневного программного окружения, и за мною как за заварившим кашу, потянутся мейнтейнеры всех других программных продуктов, которые используют этот самый gtk, пересобирать свои программные продукты с поддержкой этой самой новой версии gtk. В какой-то момент ситуация вокруг gtk стабилизируется, потому что те мейнтейнеры, которым это интересно, поднимут свои версии, а те, которым это неинтересно и которых мы давно не встречали на просторах интернета, они про это дело забудут и программы останутся неработоспособными по факту, и ситуация стабилизируется. Но потом начнётся еще что-нибудь, изменится версия какого-нибудь tcl (программного интерпретатора), и опять все начнётся по новой. Это такое вот вечно нестабильно хранилище всего, и название Сизиф как нельзя лучше отражает суть работы: вот ты значит старался-старался, компилировал-компилировал, исправлял причудливую мысль автора этой программы, который считает, что нужно заводить в корневом каталоге каталог /progs и туда все записывать, или что-нибудь в этом духе, наконец, все ошибки исправил, выложил это дело в сизиф, получил обратную связь от пользователей, еще раз какие-то ошибки исправил, а через два дня вышла новая версия этой самой программы. Значит, все, значит камень скатывается обратно и все начинается сначала.   Именно хранилище сизиф и именно в этом смысле небезопасно для повседневного использования. Понятно почему, допустим я, сопровождающий пакета, допустим, gtk (GIMP Toolkit, популярная интерфейсная библиотека графической среды, используемая многими программными продуктами), принимаю решение, что новая версия gtk, со всякими изменениями внутри, она очень хороша и я ее естественным образом у себя дома использую, и естественным образом кладу в хранилище. Что при этом происходит? Все программные продукты, которые требуют библиотеку gtk, становятся нерабочими. Потому что, библиотека новая, программные старые, собраны с предыдущей версией библиотеки, которой уже нет, вместо него я заложил новую версию, старая удалилась. Попытка воспользоваться вот этим множеством пакетов в текущем состоянии, с условием, что я туда положил новую библиотеку, приведет к тому, что библиотека эта обновится, а все другие пакеты, от нее зависящие, удалятся на вашей машине, поэтому у них есть неудовлетворенная зависимость. Это немедленно заметит сообщество, особенно те люди, которые используют сизиф в качестве повседневного программного окружения, и за мною как за заварившим кашу, потянутся мейнтейнеры всех других программных продуктов, которые используют этот самый gtk, пересобирать свои программные продукты с поддержкой этой самой новой версии gtk. В какой-то момент ситуация вокруг gtk стабилизируется, потому что те мейнтейнеры, которым это интересно, поднимут свои версии, а те, которым это неинтересно и которых мы давно не встречали на просторах интернета, они про это дело забудут и программы останутся неработоспособными по факту, и ситуация стабилизируется. Но потом начнётся еще что-нибудь, изменится версия какого-нибудь tcl (программного интерпретатора), и опять все начнётся по новой. Это такое вот вечно нестабильно хранилище всего, и название Сизиф как нельзя лучше отражает суть работы: вот ты значит старался-старался, компилировал-компилировал, исправлял причудливую мысль автора этой программы, который считает, что нужно заводить в корневом каталоге каталог /progs и туда все записывать, или что-нибудь в этом духе, наконец, все ошибки исправил, выложил это дело в сизиф, получил обратную связь от пользователей, еще раз какие-то ошибки исправил, а через два дня вышла новая версия этой самой программы. Значит, все, значит камень скатывается обратно и все начинается сначала.
Строка 54: Строка 53:
Для того, чтобы этот процесс как-то упорядочить, некое подмножество значимых программных продуктов в этом самом хранилище регулярно, скажем, два раза в год (так принято в сизифе) подвергается процедуре под названием заморозка. Замораживается весь сизиф со словами: вот сейчас, в течение месяца-двух происходит заморозка, в течение которого никакие обновления версий внутри этих программных продуктов недопустимы, если только версия обновляется вместе с устранением критических ошибок. Единственное, что разрешается делать, это устранять критические и вообще любым ошибки в ваших программных продуктах, если такие устранения появились, и вообще заниматься только этим, не смотреть в сторону новых версий а смотреть на имеющиеся, из них удалять ошибки и вообще заниматься притиркой, усушкой и утруской. В какой-то момент сообществу это дело надоедает, т.к. сообщество хочет все время новое все, и такой вот снимок достаточно стабильного состояния сизифа, когда ситуация с новой библиотекой, которая все завалила -- исправлена, этот снимок под названием ветка (branch) откладывается в сторону, после чего в этой ветке некоторое время по инициативе дистростроителей, то есть людей, которые будут делать дистрибутив, еще продолжаются какие-то изменения, но по инерции. Все, сообщество работает дальше над сизифом, который размораживается, через неделю приходит в абсолютно нерабочее состояние, потому что все туда накидают обновлений и экспериментируют вовсю, а что касается ветки, то в идеале ее стабильность может только увеличиваться с течением времени, потому что туда будут помещать исправления ошибок, если кто-то в этом заинтересован.   Для того, чтобы этот процесс как-то упорядочить, некое подмножество значимых программных продуктов в этом самом хранилище регулярно, скажем, два раза в год (так принято в сизифе) подвергается процедуре под названием заморозка. Замораживается весь сизиф со словами: вот сейчас, в течение месяца-двух происходит заморозка, в течение которого никакие обновления версий внутри этих программных продуктов недопустимы, если только версия обновляется вместе с устранением критических ошибок. Единственное, что разрешается делать, это устранять критические и вообще любым ошибки в ваших программных продуктах, если такие устранения появились, и вообще заниматься только этим, не смотреть в сторону новых версий а смотреть на имеющиеся, из них удалять ошибки и вообще заниматься притиркой, усушкой и утруской. В какой-то момент сообществу это дело надоедает, т.к. сообщество хочет все время новое все, и такой вот снимок достаточно стабильного состояния сизифа, когда ситуация с новой библиотекой, которая все завалила -- исправлена, этот снимок под названием ветка (branch) откладывается в сторону, после чего в этой ветке некоторое время по инициативе дистростроителей, то есть людей, которые будут делать дистрибутив, еще продолжаются какие-то изменения, но по инерции. Все, сообщество работает дальше над сизифом, который размораживается, через неделю приходит в абсолютно нерабочее состояние, потому что все туда накидают обновлений и экспериментируют вовсю, а что касается ветки, то в идеале ее стабильность может только увеличиваться с течением времени, потому что туда будут помещать исправления ошибок, если кто-то в этом заинтересован.
Строка 56: Строка 55:
=== Дистрибутивы ===  === Дистрибутивы ===
Строка 58: Строка 57:
Кто заинтересован в том, чтобы исправлять ошибки в наборе ПО, который уже не развивается, потому что это ветка. Заинтересованы производители дистрибутивов, т.е. продуктов, которые распространяются и фирма за распространение этих продуктов хочет получить какие-то бонусы, начиная с продажи коробок, кончая внедрением в российские школы. Допустим, какая-то фирма, допустим, Альт Линукс, хочет на базе сизифа сделать дистрибутив под названием ALT Linux Junior. Еще ни у кого настолько не поплыла крыша, чтобы делать это на базе сизифа. Разумеется, так делать никто не будет. Берется ветка, в которой все уже более или менее устаканено, никаких строгих противоречий между программными продуктами внутри нету, берется некое подмножество, поскольку дистрибутив отличается от хранилища тем, что в него входят только нужные программные продукты, хотя, некоторые нужные и не входят.   Кто заинтересован в том, чтобы исправлять ошибки в наборе ПО, который уже не развивается, потому что это ветка. Заинтересованы производители дистрибутивов, т.е. продуктов, которые распространяются и фирма за распространение этих продуктов хочет получить какие-то бонусы, начиная с продажи коробок, кончая внедрением в российские школы. Допустим, какая-то фирма, допустим, Альт Линукс, хочет на базе сизифа сделать дистрибутив под названием ALT Linux Junior. Еще ни у кого настолько не поплыла крыша, чтобы делать это на базе сизифа. Разумеется, так делать никто не будет. Берется ветка, в которой все уже более или менее устаканено, никаких строгих противоречий между программными продуктами внутри нету, берется некое подмножество, поскольку дистрибутив отличается от хранилища тем, что в него входят только нужные программные продукты, хотя, некоторые нужные и не входят.
Строка 60: Строка 59:
Есть некоторая доля содержимого, входящего в дистрибутив, но не в хранилище -- это картинки, специальные версии программных продуктов, в которых что-то перенастроено для тупых, инсталлятор, хотя он у нас весь в сизифе лежит, но мы как Debian, а у других дистрибутивов инсталлятор, как правило, пишется самостоятельно. Есть какая-то часть, в этих программных продуктах, которые даже ветке не принадлежат, но вот остальная часть берется из ветки, и дистростроитель выяснит, что от исправления ошибок зависят потребительские свойства этого дистрибутива, то в ветку продолжают вносить какие-то изменения. Вот, собственно, вам и технологических цикл. Постоянно нестабильное хранилище, в которые все постоянно помещают самые свежие версии программ, лишь бы они работали у них самих, два раза в год осуществляемых процесс заморозки, который сначала приводится в относительно стабильное состояние, потом сизиф отпускается, а сфотографированный стабильный срез продолжает жить своей жизнью, его жизнь имеет две цели * организация дистрибутивов на его основе * для тех людей, которые взяли готовый дистрибутив и им потребовалось что-то из стабильного среза хранилища. Вы взяли дистрибутив, например, lite, в котором многих программ нет, а где они есть? они есть в соответствующей ветке, из которой был сделан этот дистрибутив. Ровно так.   Есть некоторая доля содержимого, входящего в дистрибутив, но не в хранилище -- это картинки, специальные версии программных продуктов, в которых что-то перенастроено для тупых, инсталлятор, хотя он у нас весь в сизифе лежит, но мы как Debian, а у других дистрибутивов инсталлятор, как правило, пишется самостоятельно. Есть какая-то часть, в этих программных продуктах, которые даже ветке не принадлежат, но вот остальная часть берется из ветки, и дистростроитель выяснит, что от исправления ошибок зависят потребительские свойства этого дистрибутива, то в ветку продолжают вносить какие-то изменения. Вот, собственно, вам и технологических цикл. Постоянно нестабильное хранилище, в которые все постоянно помещают самые свежие версии программ, лишь бы они работали у них самих, два раза в год осуществляемых процесс заморозки, который сначала приводится в относительно стабильное состояние, потом сизиф отпускается, а сфотографированный стабильный срез продолжает жить своей жизнью, его жизнь имеет две цели * организация дистрибутивов на его основе * для тех людей, которые взяли готовый дистрибутив и им потребовалось что-то из стабильного среза хранилища. Вы взяли дистрибутив, например, lite, в котором многих программ нет, а где они есть? они есть в соответствующей ветке, из которой был сделан этот дистрибутив. Ровно так.
Строка 62: Строка 61:
==== backports ====  ==== backports ====
Строка 64: Строка 63:
Еще одно свойство бывает характерно. Есть хранилище, объявлено стабильным. В нем запрещается делать обновления, за исключением обновлений по безопасности и исправлений грубых ошибок. Что если мы хотим пользуясь программным окружением из стабильного хранилища воспользоваться суперновой программой, которой либо вообще во времена стабилизации ветки в ней не было, либо со времен стабилизации она серьёзно обновилась. Болезнь новых версий у всех есть, даже у тех осторожных людей, которые не пользуются сизифом, а пользуются дистрибутивами. Для них есть отдельное небольшое хранилище, которые поддерживается таким же сообществом больных новыми версиями, которое называется backports. Берутся пакеты из сизифа и пересобираются в окружении ветки. Предполагается, что такого рода пересборка проходит (а бывает, что нет, допустим нужна более свежая версия компилятора), предполагается что использование пакетов из backports не портит стабильности ветки, хотя это никто не гарантирует. В любом случае, это намного лучше, чем пытаться одновременно брать пакеты со стабильной ветки и из сизифа. Это уже технология достаточно полная. Понятно, что дистрибутивов может быть много разных, школьных у нас 4 разных.   Еще одно свойство бывает характерно. Есть хранилище, объявлено стабильным. В нем запрещается делать обновления, за исключением обновлений по безопасности и исправлений грубых ошибок. Что если мы хотим пользуясь программным окружением из стабильного хранилища воспользоваться суперновой программой, которой либо вообще во времена стабилизации ветки в ней не было, либо со времен стабилизации она серьёзно обновилась. Болезнь новых версий у всех есть, даже у тех осторожных людей, которые не пользуются сизифом, а пользуются дистрибутивами. Для них есть отдельное небольшое хранилище, которые поддерживается таким же сообществом больных новыми версиями, которое называется backports. Берутся пакеты из сизифа и пересобираются в окружении ветки. Предполагается, что такого рода пересборка проходит (а бывает, что нет, допустим нужна более свежая версия компилятора), предполагается что использование пакетов из backports не портит стабильности ветки, хотя это никто не гарантирует. В любом случае, это намного лучше, чем пытаться одновременно брать пакеты со стабильной ветки и из сизифа. Это уже технология достаточно полная. Понятно, что дистрибутивов может быть много разных, школьных у нас 4 разных.
Строка 66: Строка 65:
Нестабильное хранилище большое, стабильный срез хранилища -- регулярный, изготовление дистрибутивов как наборов ПО из стабильного хранилища + всякая дополнительная обвязка вроде специфики инсталлятора.   Нестабильное хранилище большое, стабильный срез хранилища -- регулярный, изготовление дистрибутивов как наборов ПО из стабильного хранилища + всякая дополнительная обвязка вроде специфики инсталлятора.
Строка 68: Строка 67:
Относительно объёмов --- хранилище содержит около 9000 пакетов. Типичный дистрибутив на DVD --- порядка 4000 пакетов, на CD --- порядка 800. Двухслойный DVD --- 8000-9000 пакетов.   Относительно объёмов --- хранилище содержит около 9000 пакетов. Типичный дистрибутив на DVD --- порядка 4000 пакетов, на CD --- порядка 800. Двухслойный DVD --- 8000-9000 пакетов.
Строка 70: Строка 69:
Посмотрим репозиторий, {{{lftp ftp.altlinux.org}}} === Посмотрим репозиторий ===

{{{lftp ftp.altlinux.org}}}
Строка 85: Строка 86:
Это все разные каталоги, тут нет строгой дисциплины, за исключением желаний отдельных людей или групп что-то поместить.   Это все разные каталоги, тут нет строгой дисциплины, за исключением желаний отдельных людей или групп что-то поместить.
Строка 89: Строка 90:
drwxr-xr-x 13 ftp ftp 4096 Jul 30 21:49 ALTLinux                drwxr-xr-x 13 ftp ftp 4096 Jul 30 21:49 ALTLinux
Строка 115: Строка 116:
 * {{{updates}}} -- обновления к веткам и дистрибутивам (по отдельности, т.к. одно и то же может обновляться по-разному из-за особенностей допилки в дистрибутивах)   * {{{updates}}} -- обновления к веткам и дистрибутивам (по отдельности, т.к. одно и то же может обновляться по-разному из-за особенностей допилки в дистрибутивах)
Строка 125: Строка 126:
|| 19 || 1 || 1 || 1 || || 1 || PavelSutyrin, VladimirLysikov, MaximByshevskiKonopko || || || || 20 || 1 || 1 || 1 || || 1 || PavelSutyrin, VladimirLysikov, MaximByshevskiKonopko || || ||

Администратор сам себя. перебираемся к курсу "Расширенный курс системного администрирования."

Репозиторий, ветка, дистрибутив

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

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

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

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

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

Хранилище

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

Мейнтейнеры

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

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

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

То есть

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

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

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

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

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

Технологические преимущества хранилища

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

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

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

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

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

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

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

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

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

backports

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

Нестабильное хранилище большое, стабильный срез хранилища -- регулярный, изготовление дистрибутивов как наборов ПО из стабильного хранилища + всякая дополнительная обвязка вроде специфики инсталлятора.

Относительно объёмов --- хранилище содержит около 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 -- обновления к веткам и дистрибутивам (по отдельности, т.к. одно и то же может обновляться по-разному из-за особенностей допилки в дистрибутивах)

{00:47:27}


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

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

20

1

1

1

1

PavelSutyrin, VladimirLysikov, MaximByshevskiKonopko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080720/01Repository (последним исправлял пользователь MaximByshevskiKonopko 2008-10-09 21:46:34)