Ядро. Отвечает за принятие стратегических решений: например, ставка на виртуалки в альт 4.0 сервер, на какой DE, ... . Второе: разработка кода, которое нельзя переложить на сообщ (напр., инсталлер)
Пользователи. Бывают два вида: которые просто им полььзуются (например, интеграторы), и от него идёт активный фидбек. Он не обязан быть разработчиком, хотя его туда легко совратить.
Второй вид пользователей --- т. н. "обычные пользователи", у них написано, куда обращаться, если что-то не получается, они и обращаются.
Лектор сейчас не сказал про разраб. Если выкинуть из разработчиков тех, которые пишут непоср. код.
Лектор помнит случай, когда ...
Главные люди, которые наполняют слой, это ментейнеры. Это люди, задача которых сост. в следующем: они берут заинть. их прогр. продукт и допиливают его так, чтобы он мог входить в состав дистрибутива.
Именно это самое важное, поскольку цели апстрима и разработчиков дистрибутива могут несоотв. друг другу и противоречить. Например, куда класть файлы, заходить на опр. сайты в процессе сборки или нет...
Собственно, весь курс посвящён именно труду ментейнера.
Ещё одна тема, зависшая с прошлого раза: дистр. и хранилище.
Мы будем говорить про форм. дистрибутивов на пустом меще, но вскользь, поск. сейчас никто не занимается созд. дистр. с нуля. Обычно, так делают разные ембеддед. Тем не менее, ни о каком сообщ., и ни о каких цикл. преоб. хранилища речи тут не идёт.
Относиткльно зранилища. Когда леткор говорит "сообщество вокр. дистр.", он передёргивает. Поск., вокр. дистр. может возн. сообщ. только в силу его уникальности, на самом деле всё происх. не так: есть сообщество вокруг хранилища, и результатом действий сообщ. явл. выпуск дистрибутива. Если найдётся субъект, который захочет изг. некое решение, то этот самый субъект полезет вот в это хранилище, возьмёт оттуда нужные себе пакеты, по причине того, что ментейнеры адаптировали это ПО так, что оно притёрто друг к другу, и из этих пакетов у него может получиться ОС.
Если посм. на списки рассылки, то польз. говорят про дистр., а разраб. про хранилище.
Структура след: есть хранилизще (напр., Сизиф), Когда речь идёт о дистр, выбирается из него некое подмножество.
Понятно, что такое живое, как хранилище пакетов, где что-то ежедневно ломается и чинится, оно не может быть дистрибутивом.
Это подмн. пакетов копируется и наз. бранчем (веткой). Это либо ветка общего назначения, либо ветка дистрибутива. В ветке пакеты только исправляются, а не обновляются, и чем дальше, тем более крупной должна быть ошибка, мелкие ошибки только документируются.
Если мы хотим сделать дистрибутив, то мы должны сделать качество ветки как можно выше.
В частности, в ветке нельзя повышать версию, за редким исключением (напр., испр. ошибок)
На основании ветки делается дистрибутив. В дистрибутив входит дизайн, установщик, ещё что-то.
Дистрибутивы могут продаваться в коробках. Где-то здесь же производится финальное документирование.
В теории, есть ещё обратное движение: что делать, если мы испр. ошибку в ветке, то хорошо бы её испр. и хранилище. Или документация.
Другой алг., с этим связанный, связан с тем, как повышается качество кода. Это простой трёхстадийный алгоритм.
- Люди делают что хотят
- Feature merge --- technical Preview
- Bugfix. На этом этапе нач. действовать правила ... --- здесь появляется Beta
Freeze -> Release. Фриз --- больше испр. ничего не надо, народ только тестирует и испр. только те ошибки, которые угр. безопасности, или грубые ошибки, приводящие к нерабочести дистрибутива. Потом вся такая информация отпр. в эррату и делатеся релиз. --- RC, Release
FHS.
FHS --- некий стандарт отн. того, как файлы должны быть разм. в дерево каталогов в типичной чичтеме. Не надо говорить догмы отн. того, что в Linux общий корень, поэтому здесь это вполне логично.
Зачем это нужно? Ответ очень простой. Если вы --- составитель дистрибутива, при уст. которого, сборника ПО, при уст. всех получается ОС, то если не будет в этом порядка, то врядли то, что получится, будет работоспособно.
Например: в типичном дистр. линукс от 500 до 1000 пакетов. Если это положить как попало, то вряд ли это будет работать.
Кроме того, есть такая вещь, как разд. библиотеки: если она лежит не там, то приложение не сможет запуститься.
Что же касается самих разраб. ПО, то этот стандарт не очень интересен. Скорее даже наоборот: если вы будете пистаь кросплатформенное приложение, что у вас файлы будут лежать в разных местах, и если следить за этим, то это получается лишняя работа.
Лектор сейчас не станет описывать, из каких каталогов состоит FHS.
Единственное, что лектор скажет, что он не очень строг, и пакет из одного дистр. может не заработать под другим, но все вещи, которые лектор перечислил, они там есть.
почему лектор об этом заговорил: мы рассм. неск. концепций разр. пакетов, и увидим, что все они ост. на ряде концепций, на этом в том числе.
Попробуем подойти к понятию пакет с точки зрения пользователя, как к прогр. продукту.
Сейчас в убунте происх. революция тихая: польз. предл. ставить не пакеты, а прогр. продукты. Поск польз. ожидают, что прогр. это нечто, что делает иконку в меню.
Польз ожидает, что пакет можно установить, удалить, обновить. Ещё работать должна, но это неважно.
Как из этого требования польз. к прогр. продукту вытекает конц. постр. пакета.
Как устр. то, что мы ставим внутри виндовса: эта прогр. снабжена специальным инсталлятором, этот инсталлятор модифиц. настр. системы, созд. иконку, контр. версий. Получается такой дистр. в миниатюре.
Возн. проблема с разноверсицей.
Второй вариант — configure && make && make install. Дальше уже проблема автора этого продукта --- как он отслеж. проверку конфл. и так далее.
Лектор сразу скажет, если бы вся операционная система сост. ... даже Slackware и LFS отошли от этого способа.
Поэтому мы ост. на 4 подходе: он состоит в том, что у нас уже есть инстр., который позв. избежать хотя бы конфл. по файлам в пакетах. Если мф договоримся, что наше ПО уст. не куда попало, а согл. стандарту на ФС, то мы можем сокр. количество мест, где лежат библ., до 2-3, где лежат бинарники, до 4-6, то есть, сделать пространство поиска вполне обозримым, и сказать, что пакет --- архив. В самом деле, вместо того, чтобы писать инсталлятор, мы можем разарх. пакет в системе, и мы всегда можем проверить, не будет ли он конфликтовать, и эту задачу уст. решить супертривиальным способом. Однако, возн. неск. вопросов, с этим сязанных ,которые можно решить задёшево. Если мы договорились, что это архив (это легко проверить --- rpm --- cpio, deb --- tar.gz, tar.bz2), то для контроля принадл. достаточно записать, что мы и куда разарх. Далее, можно считать контр. суммы и проверить, не подвергались ли они изменениям. То есть, мы берём процедуры установки, встроенную в систему (не в прогр. продукт), то это не только разарх., но и регистр. разных параметров в БД. Кроме того, можно пометить файл, как конфигурационным, тогда можно это обр. специальным образом: например, изм. конф. файлы сохр. при удалении. Особенно это важно для обновлений.
Помимо того, есть действия, специфичные для каждого пакета. которые надо выполнять при его уст. и удалении. Напр., парсеры конфиг-файлов. Виды сценариев:
- preinstall, postinstall
- preuninstall, postuninstall
Чем это отлич. от пред. пункта? Эти действия пакет делает сам в момент уст. и удаления.
На самом деле, есть промежуточная стадия: пример с ldconfig может быть сведён к предыдущему: соверш. необяз. каждому пакету с библиотекой писать в скрипте ldconfig, поск. это соверш. очевидно. Та же история с иконками.
Такими вещами занимаются штуки под назв. триггеры, это такой компромисс между 2 и 3 пунктом.
На этом заканчивается св. пакета отн. ОС.
Обновление. Это такое специальный сценарий установки-удаления, при котором надо сначала удалить, потом уст. обратно, при этом удалять надо не всё. Это опис. в рег. в системе и втриггерах.
Кто принимает решение о том, что пакет надо обновлять? Пока не совсем понятно, поск. непонятно, по каким признакам это опр., и откуда новую версию брать. Об этом позже.
Если посм. пакет в сост. дистр., что увидим: в первую очередь, вылезет такая штука, как зависимость. Что такое завис. пакета? Типичный пример, коогда проблемы нет --- первы вариант.
Но логично не таскать с собой, а указывать зависимость. Лектор попробует сегодня расск., какие у этого эсть полож. и отр. св-ва. Какие есть виды зависимостей:
- На пакет
- На файл. Довольно забавная вещь, непонятно,когда она нужна. Откуда она возн: мы не знаем, какой пакет
- На функциональность (на вирт. пакет). Почему она самая популярная? Если есть неск. пакетов, которые предост. одну и ту же функц., поставить их может быть тяжело. Но зависимость нам нужна не на конкр. пакет, а на функц., мейлсервер. "25-й порт у нас только один"
Другая причина исп. вирт. пакетов --- когда есть некая стандартизованная дисц., как оформлять имена вирт. пакетов на библиотеки. Например, если зависимость на месц, то пишете не глядя зависимость на libmesa.
Версии пакетов можно указывтаь, причём не только конкретные, но и >=/<=/>...
Чтобы опр. зависимость, нужен только данный пакет. Поск. они указаны в нём. Далее прогр.=уст. посм. на список установленных пакетов. Но для разреш. зависимостей нужно знать о всех пакетах.
Кроме того, видов зависимостей бывает неск., в дебиане, напр., их 4 (predepends, requires, recommends, suggests).
Например, для веб-морды необх. зависимость на веб-сервер, recommends на ssl, suggests на почтовый сервер.
В rpm разных видов зависимостей нет.
На завтра: разг. про разд. библиотеки.
Сегодня ост. договорить про две вещи.
Неудв. зависимости. Когда пакета нет в системе. С точки зрения пакетного менеджера --- его ещё и поставить неоткуда. Эта шутка наз. unmet, и для хранилища это норм. ситуация. Правда, в Сизифе их становится меньше и больше их не будет.
Вообще ситуация unmet --- опасная, значит, какой-то непорядок с хранилищем.
Вторая ситуация --- конфликты по файлам. Например, есть несклоько текстовых редакторов, каждый из которых хочет называться vi. Например, vi, vim, elvis, nvi. Вообще, можно пост. только один пакет в один момент времени. Если зочется поставить больше, то ментейнер должен быть знаком с понятием "альтернатива". Тогда файла /usr/bin/vi нет, есть vim, но ментейнер прописывает альтернативу, и /usr/bin/vi будет ссылаться в alternatives, а оттуда уже на нужный пакет. При этом существуют правила в виде весов, и есть интерфейс, который позв. эти рулить.
Есть одна важная тема: уст. и менеджеры пакетов. Факт, лектор её уже рассказал.
Есть установшик пакетов. Она умеет работать с одним пакетом (alt - rpm, debian - dpkg). Она может проверить зависимости. Даже рекурсивно она удалять не умеет.
Для рекурс. удаления и установки, или обновления. Для этого нужно иметь инф. о хранилище. Такая прогр. наз. менеджер (диспетчер) пакетов, и она работает с хранилищами. В альте исп. apt.
Задача диспетчера составить индексы всех дост. зранилищ, дать пользователю возм. искать по ним, и в случае необх. установки получать их и уст. в нужном порядке. Также, только дисп. доступна процедура обновления.