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

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

Мы поговорили про установщик и менеджер пакетов. Пакет нужно удалять и устанавливать. Ровно эти две функции вып. уст. рпакета (ещё просмотр инф. о пакете). Это озн., что если у нас есть файл, сод. пакет, то мы его можем просто установить (rpm -i). Если у нас есть уст. пакет, то мы можем его удалить (rpm -e). И ещё можно инф. посмотреть (rpm -q). Чего не может делать уст. пакетов: он не может вычислить деерво зависимостей для уст. и удаления: совреш. непонятно, откуда брать доп. инф. о том, чтобы он установилс нормально. С этой задачей справляется диспетчер пакетов. У него две функции --- работа с репозиторием и работа с пакетом. Он умеет обновлять пакеты, и вообще делать ту работу с системой, которая обычно для обновления системы нужна.

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

Есть апстрим, который периодически попродлает релизы программы, и откудаа ментейнер берёт исх. коды.

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

Точно также, вручную, делаются вспомог. сценарии: подредактировать такой-то конфиг, передёрнуть такой-то демон. Хотя, можно сделать доволно много по части миним. действий мант. по части напис. вспомог. сценариев, перекладывая это на триггеры. Пример того, что этим не решишь проблему: допустим, леткор решил писать инф. портал, из котоорого можно смотреть и man, и info, ... . В частности, есть тулза, которая запускает для каждого пакета rpm -q и форм. один html. Представьте теперь, что лектор вписывает перегенерацию его в качестве триггера.

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

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

В итоге мы имеем некий спек. Фактически, мы сейчас описали структуру расп. прогр. продуктов в BSD --- система ports. Вы собираете програму согл. некоему аналогу спека. Ососбеностью у них явл. то, что исх. файл не хранится, а скачивается. Понятно, что если версия обновится, то оно может поломаться. Поэтому в больших fbsd-серверах делают dist-files и обычно лезут первым делом туда. единст. цель, с которой это делается --- чтобы обесп ..., и скачивать только совсем несв. программы. Потом в процессе уст. подсовыввается спец. инстр., который логгирует процесс установки. Если необх. зарег. зависимости, это делается вручную. Там есть некий инстр. по авт. выстр. зависимостей, но он. связан не с проверкой системой, а с проверкой makefile.

Лектор этот подход считает не то, что неправильным, при грамотной орг. сборочного компьютера он правлиьный, но есть сущ. недост. --- сборка пакета происх. на боевой системе.

Тепрь ост. на проблеме сбороч. зависимостей: мы не описали фазу 0 --- для того, чтобы прогр. собралась, на том компьютере, на котором она собирается, должно быть много всего, что для обыденной жизни не нужно.

Первый подход --- ставить всё. Что не очень хорошо.

Второй вариант --- ставить доп. пакеты при необх.

В Сизифе сбороч. завис. минимизируются. Есть buildreq. Он позв. отследить довольно много сбороч. зависимостей, и этот самый спек я ему пытаюсь сбор. по-новой автоматом.

В альте сделано весьма много, чтобы сделать подсч1т сбороч. завис. автоматизировать. Не только автомат. запуск тех или иных

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

Есть такой трюк, когда завис. уст. выч. при помощи завис. сборочных. Но это трюк, и он работает только в случае, когда всё работает в одном флаконе.

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

Мы сейчас рассм. ситуацию сборки в баз. системе. В чём вред:

С точки зрения хранилища уник. сборки это очень большое зло.

Этот комплект проблем можно решить одним махом --- мзолированной сборкой. Она решает все наши проблемы.

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

Что предл. делать под линуксом: (изолир. сборка)

  1. Как бы то ни было, сборка из-под рута --- вредная вещь. До появл. openvz надеяться на нормальную сборку с поиошью рута было тяжело. Поэтому помимо изол. на уровне ФС ( chroot), происх. также специальная подмена рута нерутом. поэтому дост. в чрут поставить сбор. зависимости.
  2. Мы не хотим рута. Есть fakeroot. В ркз-те процесс, запущ. от fakeroot, будет считать, что он от рута, созд. файлы и видеть, что они от рута. Те вещи, которые можно делать только рутом, fakeroot симулирует (и записывает о них в лог). По сути, fakeroot это загруженная через LD_PRELOAD библиотека, подм. разные сис. вызовы.

После чего мы можем перейти к след. схеме:

Какой недостаток: для сборки каждого пакета нужно заново разв. сбор. среду. Практика подск., что сборка в hasher в случае нахождение в /tmpfs, происх. примерно в 6 раз быстрее, чем просто на фс.

Это чуть ли не единст. релаьный ндеостаток.

Достоинство номер 0 (ради чего это затеял Дима): мы получаем верифиц. полностью контр. сбороч. среду.

Рез-т номер 1: изолир. сборка по данным принципам позв. сделать воспр. сборку.

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

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

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

LecturesCMC/PackageMaintaining2009/Conspects/03/eSyr (последним исправлял пользователь eSyr 2009-10-15 13:20:30)