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

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

Хранилище. Ещё его часто называют словом репзиторий. Это такая довлоьн инт. штука. С тчки зрения чел. совсем не в курсе оно выгдяит как свалка продуктов, где находится ПО, адапт. к дистрибутиву. Если приглядеться, то можно увидеть, что есть неск. вс-в, кторые его делают не прсто свалкой файлов. Во-первых, пакты туда кладут члены сообщества. При этом членом собщества может стать не каждый, но дост. доказать свою возм. их сбирть. В репозиторий помещ. собранные пакеты и исходные варианты ПО, адаптированные к дистрибутиву. Поещают их менетйнеры, и пакет попадает туда не сразу. Первым делом происх. проверка на пригоднсть, то, наск. собл. полиси (в альте эт sisiphus-check). В яде случаем это довольно строгая процедура. В случае с сизифом закачивается src-rpm, робот пытается собрать этот пакет, и если не удаётся, то разработчик бил в бубен и пакет не помещается. Был бы неплох, чтобы где-то были правила по тестировнию. Но вот таког не присходит, поск. это не всегда легк рганизовать. Прверяется обязательно собираемость, проверяется соотв. дисц. сборки. Предп., чт если ментейнер его поместил, то эт зн., что н им польз. и то, чт он её пользх. есть дост. жэфф. способ тестирования. Тут стоит заметить, что эта подсистема сборки в изолированном окружении в сообщ. сизиф наиболее продвинутая и технологичная. В дебиане примерно аналогично, в других дистр. пожиже. Лектор может отолать к статьям Димы Левина про сборку в сизиф и про хэшер.

В первый день лектр говорил, что длжны быть предст. технологич. преимуществА, вот они и есть.

Надо сказать, что полскольку (мы затр. эту тему в позапр. раз --- разд. библ.) прогр. прдукты взаимд. друг с другом, напр., прграммы для граф. подсистемы польз. целым мнж. инструментв (граф тулкит, мат. библ, ...) и каждый из этих компонентов явл. тдельным прорг. продуктом и лежит в хранилище отдельн от другог. В этом смысле хранилище сизиф небезопасно для повседневного пользования. Например, ментейнер gtk, дост. популярнй инт. библитеки, собирает нвую версию и кладёт в хранилище. Что происх: все прогр. прдукты, исп. её, становятся нерабочими. Ппытка восп. этим мн-вм пакетов с условием, что ..., приведёт к тому, что библ. обновится, а прилож. все удалятся. Это заметят, особенно те, кто таки сизиф исп., и ментейнеры начнут пересбирть свои пакеты. В какой-то момент ситуация вокруг ПЕЛ CN,BKBPBHETNCZ, и все активные прилож. обновятся, а неактивные так и будут лежать. Это такое нестаб. хранилище, и назв. "сизиф" его отражает.

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

Тут над упомянуть ещё дно св-во. Вот у нас есть хран., объявленное стабильным. В нём запр. делать обн., за иск. обн. безп. Чт мы хотим, пользуясь окр. вот этим, хотим восп. суперновой программой? Для них есть отд. хранилище, backports. Чт эт такое? Берутся пакеты из сизифа и пересобир. в окр. ветки. Такое зачастую прохдит и считается, что ничего не портит. Это лучше, чем брать пакеты из сизифа.

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

Посмотрим репзитрий, lftp ftp.altlinux.org. Тут лежит всё, что считают нужным иметь ментейнеры. Можно видеть апдейты, бэкпорты, сизиф.


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

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

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

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

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

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

Level

Maintainer

Start date

End date

0

1

1

1

1

PavelSutyrin, VladimirLysikov, MaximByshevskiKonopko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex