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

Сегодня вспоминаем, что такое пакет с точки зрения пользователя. Это материалы первого из трез прошедших семестров и считается, что уже известно, так что глубоко останавливаться не будем. Итак, наша тема -- пакет как программное обеспечение.

Пакет, как программное обеспечение

Нам интересно посмотреть, как дистрибутив гну линукс состояит из отдельных компонентов-пакетов и составляет операционную систему. Первое и самое очевидное применение пакета -- устнаовка.

Как происходит установка комплекса по?\

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

Следующее действие -- удаление. Удаляем все файлы, делаем пометки что пакет удален и ещё кое-что.

Обновление пакета. Сначала удалить потом ставить новый или сначала ставить потом удалять? На самом деле обновление -- не суперпозиция удаления и установки.

Интересно посмотреть на установку дистрибутивов, который ставятся не установкой пакетов, а разворачиванием готового бинарного образа. Это довольно интересно. Что остается от пакета если из установки вычесть собственно разворачивание архива? Возможно, мы на этот счет поговорим.

Помимо структуры самого пакета к процедуре управления пакетами имеет отнощение ФХС. Идея состоит в том, чтобы строго регламентировать какого типа файлы в каком дереве каталогов должны лежать и мы получим ситуацию, что даже не разглядывая файлы в пакете, мы можем сказать, где у него бинарники, где документация, где иконки. Знаем не только мы, но и установщик, поэтому та же установка иконок легко автоматизируется. Но это +-, потому что ФХС очень медленно развивается, и то, что в него включается, успевает устареть.

С одной стороны наполнение файлами соответствует содержимому пакета, с другой -- стандарту, принятому в дистрибутиве. Собственно, в идеале ничего кроме этого не существует. К идеалу близко подощел дебиан.

На основании этих двух посылов

  1. пакет это нечто, что можно устанавливать удалять обновлять
  2. раскладывание файлов подчиняется стандарту

Итого пакет это архив.

Дерево: /

Итого, представляем себе пакет архивом, который распаковывается в нужные места.

Что будет если два пакета захотят положить в одно и то же место один и тот же файл?

Но у нас ещё есть задача удаления. Надо хранить список файлов в пакете, чтобы можно было их удалить. Ещё хорошо бы хранить контрольную сумму. Ещё есть такое, когда некоторые файлы надо удалять вместе с пакетом. Какие-нибудь генераты, ещё что-то. То есть, при удалении пакета некоторые файлы могут ему принадлежать, и могут не существовать. Ещё забавней с конфигами -- с ними надо поступать особым образом,если их редактировали. Отредактированные конфиги нехорошо удалять вместе с пакетом. Настраивал человек сквид всю ночь, к утру разозлился и удалил его. Плохо будет, если его работа за ночь удалится. То же самое при обновлении - их лучше не обновлять, а класть новый рядом. При удалении переименовывать так,что бы можно было потом найти.

Итого, пакеты надо регистрировать, хранить дополнительные данные про них. ФХС не настолько развесист, чтобы угадывать тип файла.

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

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

Как известро постфикс и ... состят из нескольких процессов, а постфикс ещё и из нескольких пакетов, один из которых либпостфикс. При обновлении отдельно обновляется библиотека, потом пакет. Пока не придумали хорошего способа останавливать постфикс от начала обновления библиотеки и до обновления постфикса, особенно в сочетании с одновременным обновлением 100500 пакетов. То есть, сложно сделать, чтобы сценарий одного пакета влиял на другой.

В некоторых дистрибутивах, например, дебиан, выделен ещё один параметр -- когда мы настраиваем установленный пакет. Разложили файлы и хотим пакет запустить. В дебиане выделен в отдельное место настроечный сценарий. Это сделано ещё и потому что там единая дырка конфигурирования всего -- дебконф. Унификация такого интерфейса позволяет автомотизироват процесс настройка, запоминания настройки и применяя их потом. Но он гиков и для тех, кто знает, что писать в конфиг файлы.

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

Всё вышеперечисленное пользователь пакета может как знать, так и не знать. А вот то, что он не может не заметить, это зависимости. Имеются в виду установочные, а не сборочные зависимости. Самое простое -- какая нибудь разделяемая библиотека, которая нужна бинарнику.

Пакеты по бывают трех видов

  1. пакет дистрибутив, в котором ездит всё, что нужно пакету. Достоинства -- вы никак не завязаны на другие пакеты. В линуксах, как правило, возят они с собой не совсем всё, и это может быть источником проблем -- оно может быть собрано в предположении о наличии каких-либо библиотек, а их может не оказаться. В виндоусе часто возят с собой совсем всё, или собирают статически. Проблема -- разноверсица загруженных в память бибиотек, их в памяти много, и они могут предоставлять одинаковые символы. Есть современная модификация, когда каждый пакет запускается в изолированном окружении. НиксОС вроде устроен так же.
  2. Старый добрый линуксовый метод -- пакет это только те файлы, которые отличают ваш программный продукт от ос. Библиотеки лежат в других пакетов. Главный недостаток -- зависимости. На каждый пакет возникает дерево пакетов, которые ему необходимы. Плагины к чему не будут работать без чего-то, игры не будут работать без нужных им данных, инструменты для разработки -- дев версия библиотеки вытянет основную версию. Помимо этого майнтейнер может вписать зависимости в пакет руками. (Предыдушие варианты были про автоматически определяемые зависимости). Пример автоматически не определяется, если вы из какого-нибудь скрипта вызываете какую-нибудь утилиту. Зависимость на эту утилиту надо вписат руками. Помимо строгих зависимостей есть нестрогие. У вас есть вебпочта. Пачка скриптов на пхп. Ни в одном из них не написано, что для работы нужен вебсервер. Включать в зависимость? А вдруг белочек много, а вебсервер можно один. Или нужен ли ссл-модуль? Его тоже может не быть. ссл -- типичный пример рекомендованной зависимости. веб-сервер -- пример предполагаемой зависимости. А какой вебсервер ставить по зависимости? Ваш любимый. Помимо зависимости на пакет может быть зависимость на виртуальный пакет, отвечающий за какую-нибудь функциональность.

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

Был скандал -- опера сделала пакет под альтлинукс, все зависимости на библиотеки файловые. Дня три она была совместима с сизифом. Потом писали специальный пакет, который подкладывал пустые файлы с нужными именами.

В рпм5 появились нестрогие зависимости, в рпм4 такого не было.

Недавно нашли багу в дхцп. Если попытаться отдать /8 дхцп, то происходит сегфолт. /9 говорит - не хватит памяти, а /8 -- падает. Правильный ответ -- не надо хотеть /8, никогда на одном езернете не будет 16 миллионов абонентов. Но падает же. Нашли почему.

Конфликтующие пакеты. Если один и тот же файл предоставляется разными файлами. Например /usr/bin/vi много кто хочет, а предоставляют его несколько пакетов. Решение -- называются файлы у всех по разному, и делаются симлинки, и ручка, которая может передергивать эти симлинки на разные наборы файлов. Ситуация не очень частая, но случается.

Это что касаемо свойств пакета. Главный недостаток зависимостей -- вы скачали пакет, не факт, что вы его сможете поставить. Скачали пакет с сайта производителя, а он не ставится, а просит разного. Необходимость работать с деревом, а не множеством по.

Достоинства

  1. экономия место. Смешно, при нынешних размерах, но -- размеры дисков увеличиваются сейчас медленней, чем размеры ПО.
  2. отсутствие разноверсицы, особенно если в хранилище есть контроль консистентности.
  3. при необходимости пропатчить библиотеку -- обновлять придется один пакет, а не все, которые её используют.

В контексте сообщества, итого, зависимости весьма полезны.

Для работы с пакетами существуют

  1. установщик. Работает с файлами-пакетами. Умеет устанавливать, удалять, обновлять. Работает с системой, отслеживает зависимости, может отказаться ставить, если зависимости не стоит, и сказать, чего не хватает. В альтлинуксе используется RPM4. Работает с файлами .rpm. Таким инструментом много не поустанавливаешь.
  2. диспетчер. Работает с хранилищем/ами. Не только видел пакеты, но составлял деревья зависимостей, списки, и так далее. Составляет актуальные списки пакетов. Хранилищ может быть много, пользователи убунты знают. Диспетчер по имени пакета может понять, о каком идет речь, и какие пакеты надо поставить по дереву зависимостей. При удалении тоже скажет, что если вы хотите удалить вот этот пакет, то вот ещё надо полсистемы снести. Также осуществляет доставку пакетов и выполняет массовые операции обновления и установки (при этом "атомарные" операции отдаются на откуп установщику). В альте используется apt. Из апстрима уже не обновляются. Апт в принципе не очень удобная штука -- люди не знали математики, когда его делали -- его скорость работы печальная штука. Не очень хороший код, но по возможностям -- сильная штука.

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

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

Пример -- ставите вы кде. В метапакете щли опенофис, итп. А вдруг вы захотите снести кде, но оставить опенофис? В общем, вопрос сложный.

Домашнее задание. Поставить в виртуалбокс. AltLinux Centaurus 6. При установке тыкаете галочку "средства разработки". Места выделить гигабайт 16 (по версии из зала достаточно 2). После установки снимите снапшот. Будем превращать операционную систему в свалку. Ещё её стоит обновить до п6.

LecturesCMC/PackageMaintaining2013/Conspects/01 (last edited 2013-03-01 16:12:37 by Allena)