UNИX, осень 2009, 03 лекция (от 14 октября)

Материал из eSyr's wiki.

• Аудиозапись: http://esyr.org/lections/audio/uneex_2009_winter/uneex_09_10_14.ogg

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

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

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

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

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

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

• Сборка программы. Если это не однофайловая программа, то разр. наверняка исп. некий инструментарий. Этот инстр. может быть разнообразный, сущ. неск. дисциплин работы с большими проектами, некоторые из этих дисциплин совершенно непригодны для сборки в качестве пакета. Например, фар уже три года как опенсорц, но его не собрали в том числе потому, что тулчейн заточен под винды. Или же бывают разные случаи: только make (тогда программа либо очень простая, либо онар аботает ровно на одной операционной системе -- ОС автора), autotools (позв. с помощью спец. заготовленных сценариев генерировать сначала профиль, потом на его осн. генерировать make). Обр. внимание на то, что далеко не всегда сборка это --- configure && make. Какие проблемы могут возникнуть:
  • Ошибки сборки. Напр., человек не поставил нужную дев-библиотеку. На самом деле, это важно, поск. если апстрим не пишет список req, то это надо выясн. самостоятельно. Но есть и более важне вещи: у апстрима может быть не самая свежая версия компилятора, они могут плеваьт на FHS, они могут не замечать того, что какие-то дин. символы не разрешаются никуда, ..., возм. много ошибок сборки, которые у апстрима нет, а у ментейнера появятся. Особенно это актулаьно для альта, где очень строгие полиси. Ошибки сборки часто испр. патчами. Патч --- специальным обр. оформленный файл, где написано, чот было, что стало. Для надёжности указ. контекст. Кроме того, patch умеет искать контекст. Поэтому технология патчинга дост. удобна в смысле сизифива труда.

  Рвбота ментейнера --- сизифов труд: он её патчил-патчил, залил пакет, а через два дня вышла новая версия.

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

  • Параметризация сборки.

  Где-то внутри нашего каталога появились бинарники. Следующее, без чего нлеьзя сделать пакет:

• Создать список файлов. Тут есть два подхода --- неправильный и треб. доп. тех. усилий. Первый способ --- ментейнер высасывает список файлов из пальца. Есть ещё один непр. подход --- а давайте мыф таки да сделаем make install. Что мы от этого получим: файлы уст. куда-то, куда заблагоросудилось апстриму, наверное, в /usr/local или /opt. Согласно FHS, /usr/local содержит недистр. вещи. Чем этот подход прельщает: когда он уст., мы будем следить, и этим этот подход прельщает. С помощью LD_PRELOAD можно сделать так, что мы узнаём все имена файлов. Если эти файлы были уст. в непр. места, то мы должны изобр. патч. на configure, или лезть руками в makefile.
  • Регитсрация в системе: зависимости. С нии труба. Никакой ручной работой просто так список зависимостей внутрь пакета не вставишь. А для тго, чтобы список завис. по бибилотекам, ничего сложного не надо --- есть, нарп., ldd. Этого дост, чтобы сформировать в этом плане список зав. очень точно. В альте rpm даже не нужен, поск. из имени библиотеки и версии можно понять, какой пакет её провайдит.
• Паспорт пакета. Абсолютно ручная работа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Захламление. Ваш компьютер предн. для работы, а не для сборки. Чтобы закончить тему в fbsd: во fbsd есть jail, его аналог в linux есть vserver, сейчас есть openvz, это более крутая штука. Идея в чём... Если мы набл. за тем, как собираютс пакеты, то можно заметить, что никакой уст. в базовую систему не происх.. Тот make install происх. не в базовую систему, а в подкаталог. Это, кстати, хороший тест на кач. продукта --- можно ли его так поставить. Прблема реш. крайне просто --- дичц. устроена таким. обр., чтобы можно было уст. как в наст. систему, так и в любое место, и чтобы от этого ничего плохого не происх. В рез. форм. дерево катлогов, в котором лежат только те файлы, которые нужны при уст. Т. о. мы изб. от первой и самой главной опасности --- не требуются права суперпольз. Но это не решает двух других проблем: не решает проблему мешанины сбор. средств, и не решает проблему уник. сборки. Если вы собир. пакет в базовой системе, то каждый пакет, условно говоря, униклаьный. Главный рез-т того, к чему мыприходим --- униккален по отн. к пред. сборке себя же.

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

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

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

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

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

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

• Созд. chroot и уст. туда все нужные сбор. пакеты, засовывает туда src.rpm, и говорим, вот теперь там собирай.

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

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

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

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

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

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

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