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

Начнём с конца.

Что умеет apt?

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

apt -- инструмент работы с хранилищами, у которого две части:

  1. работа с хранилищами
  2. работа с локальными индексами хранилищ.

Традиционно такое разделение было задизайнено в 90ые годы, когда доступ к удаленном хранилищу был проблематичен, установка часто производилась с дискеты или сидюка, и тд. Логично было сосредоточить операции, для которых не нужны сами пакеты на локальной машины. С помощью апт-гет можно было апдейтить эти кэши, и всякие операции типа поиска и выдачи нужной информации проводились на локальной машине.

apt-get и apt-cache

Основные команды:

Мы говорили об использовании апта как елси бы у вас список репозиториев прибит гвозядми. Традиционно у апта есть файл /etc/apt/sources.list и в каталоге /etc/apt/sources.list.d все файлы. Схема .d возникла в дебиане. Там есть полиси, которая требует, чтобы при установке и удалении пакета не модифицировались файлы, принадлежащие другим пакетам. Довольно сильное требование, учитывая что при устанвке запускаются сценари, из которых можно редактировать конфиги. Итак, есть возможность редактировать конфиги, но это дожны быть конфиги строго этого пакета. Если вы ставите пакет, содержащий дополнительный репозитрий для альта, в этом случае редактировать /etc/apt/sources.list запрещено. Или, например, вы ставите модуль для апаша. Вам запрещено редактировать httpd.conf. Как бы всё это совместить? давайте научим модуляризированные программы читать не один файл, а все файлы лежащие в каталоге, который называется что-то такое .d Теперь пакет кладёт свой файл в эту директорию, и другой пакет подхватывает этот конфиг. Это оказалось достаточно удобно, потому что куча конфига теперь состоит из маленьких кучек, в которых удобней разбираться и что-либо туда вхакивать. Эта схема вам встретаится довольно часто.

Что содержит в себе такой файл?

Описание репозиториев в следующем формате тип [электронная подпись] способ_доставки название разделы

Тип -- для альта rpm или rpmdir

Подпись -- у каждого зранилища своя собственная подпись.

способ_доставки -- http, ftp, rsync, file: copy: . Если ставите file:, то доставки не происходит. Предположим у вас хранилище на удаленном диске, вы обновляете, обновляется nfsd. При этом если тип файл, то апт будет считать, что у него всё есть. Обновит апт и у него внезапно отвалится то, откуда он обновляется.

Предположим у нас свалился дист апгрейд посередине. Говорите снова дист-апгрейд, а он говорит -- у вас текущие пакеты не согласованы, не буду ничего обновлять, не понимаю, дерево зависимостей чего от чего строить. Правда, апт тут же напише рецепт, напишите apt-get install fix-missing или apt-get install fix-broken и к тому, что останется, можно уже будет применять процедуру построения зависимостей.

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

rpm [alt] http://sysyphus x86-64 classic debuginfo

Такая запись не даст обновлять по человечески. Название x86-64 намекает, что пакеты бинарные.

rpm [alt] http://sysyphus noarch classic

rpmdir

Репозиторий это довольно строго организованная иерархия файлов, которая включает всебя правильно разложенные пакеты, индексы и дополнительную информацию. Генерация репозитория из списка файлов -- довольно долгая операция. При зеркалировании считается нормальным не перегенирировать индексы пакетов. Предположим, вы собиираете пакеты сами. Было бы круто не перегенировать индексы, когда хотите поставить собранный пакет. rpmdir служит для этого -- ему говоришь директорию, в которой просто так свалено штук 20 пакетов, и он сам с ними разбирается.

apt-repo скриптик есть в альте, используется для тестирования сборочных заданий. Когда посылаете задание сборочнице, можете сказать, что это тестовая сборка. сборочница будет его собирать так, как будет собирается положить его врепозиторий, но не кладет.

apt-config позволяет не редактировать аптшные конфиг файлы. Структура у них достаточно развесистая, и не всегда удобно лезть руками. Ещё ему можно сказать dump, и он напечатает всё что думает о своей конфигруации в данный момент.

apt cdrom механизм работы с сорсес листами, привязанный к ситуации, когда дистрибутив лежит на одном или нескольких внешних носителях. представьте себе ситуацию, когда у вас дистрибутив на одном или нескольких сидюках. Установка при этом может превратится в диджейство. Специфическая штука, которая показывает, насколько задача доставки неоднородная -- иногда надо и пользователем поуправлять для добычи пакетов. Ещё съемные носители надо правильно монтировать и демонтировать, понимать какэти носители называются. Есть специальный протокол сдром, который это описывает.

apt-shell . Комплишен. Легче чинить последствия неправильных репозиториев.

rpm

Задачи:

  1. установки, удаление, обновление. rpm -i, rpm - r, rpm -u
  2. проверка. Отдельный кусок работы с пакетами это проверка их цельности, сотояния установлен или нет и так далее. Это побочный результат той части установщика, которая называется регистрация пакета в системе. rpm -v
  3. информация. Может взять только из уже имеющего пакета, зато всю подноготную. rpm -q
  4. сборка. Не так уж далеки и сегодня инструменты по установке и по сборке. rpm -ba (???)

Каждая функция выполняется своим бинарником.

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

Для сборки.

Необходимо поставить все сборочные зависимости.

рпм глядит в спек, смотрит, удовлеторены ли сборочные зависимости.

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

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

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

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

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

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

Собрали в пакете библиотеку, которая предоставляет конфликтыне символы. Положили файлы не туда. Всякое бывает. Есть куча способов собрать неправильный пакет. Для этого есть пачка скриптов, которые лежат в \usr\lib\brp.d

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

Чем мы закончили?

Мы сидим, как дураки, выполняем какие-то рецепты. Пора уже начинать собирать пакеты по человечески.

LecturesCMC/PackageMaintaining2013/Conspects/03 (last edited 2013-03-22 15:46:06 by Allena)