Пакеты с точки зрения пользователя, который зашел дальше, чем нажатие на кнопочки в графическом интерфейсе диспетчера пакетов. Почти наверняка етсь неокторое гуи, которое предоставляет список паавкетов из всех хранилищ, возможности по их установке, удалению и обновлению. Пользователь, которому достаточно понаставить и оновить вполне удоавлтевориться этим интерфейсом или аналогичными командами командной строкуи. Но, далеко не всегда этого достаточно. Для того, чтобы посмотреть, где и как этого недостаточно лектор приведёт пример. Альтлинукс достаточно нетрадиционен -- он использует в качесте носителя рпм4 с разным количеством патчей (более 50 процентов кода являются патчами). Апт в качестве диспетчера. Арк линукс устроен также.
Начнём с конца.
Что умеет apt?
Из того, что мы говорили следует, что понятие пакет для конечного пользователя довольно тёмное. Особенно это хорошо видно на пользователя дистрибутива убунту. Для них обычно совершенно непонятно, зачем 100500 пакетов в репозитории. Поэтому был тренд изобретать ещё более графические интерфейсы, в котором вместо списка пакетов пользователь видел бы список приложений с детальными описаниями, наподобие портала. Одно время альт пытался этим заняться, но это приуныло, потому что пользователей, которые будут сами ставить приложения и не будут интересоваться пакетами -- мало. Или они не ставят сами приложения совсем, или минимально разбираются.
apt -- инструмент работы с хранилищами, у которого две части:
- работа с хранилищами
- работа с локальными индексами хранилищ.
Традиционно такое разделение было задизайнено в 90ые годы, когда доступ к удаленном хранилищу был проблематичен, установка часто производилась с дискеты или сидюка, и тд. Логично было сосредоточить операции, для которых не нужны сами пакеты на локальной машины. С помощью апт-гет можно было апдейтить эти кэши, и всякие операции типа поиска и выдачи нужной информации проводились на локальной машине.
- apt-get работает с удалённым
- apt-cache инструмент работы с уже скачанными индексами -- показать информацию, поискать в ифнормации, показать список пакетов, файлов, зависимостей.
apt-get и apt-cache
Основные команды:
- apt-get
- install установка с зависимоятми. Особенности -- можно подсунуть локальный файл, сообразит зависимости с хранилищем. rpm -i не захочет ставить зависимости, а apt-get install может. Примерно так устанавливаются проприетарные пакетытипа skype. Вторая особенность -- рекурсивно вычисляя дерево зависимостей, он это делает на базе локальных кэшей. Если не сдлетаь ap-get update, то apt-get install может принять решение на основе устаревших данных и попробовать скачать несуществующий файл. Поэтому, прежде чем делать install, надо делать update.
- remove удаление с зависимостями.
- есть ещё обновление, причём практика показывает, что самый правильный способ обновления dist-upgrade. Обновились какие-то пакеты. Вам надо обновить всё, что устарело. Обновление выглядит как удаление старого и установка новго, но с разными плюшками, типа специальной обработки конфигов и ещё кое-чего. dist-upgrade приводит установленные на вашем компьютере пакеты к максимально близкому к подключённым хранилищам состоянию. Пакеты, которые зависят от устаревших пакетов предлагается удалить. Раньше репозиторий мог превратиться в состояние, когда dist-upgrade мог предложить снести весь гном чтобы обновить libgtk, с которой ещё ничего не собрано. Чтобы упростить эту ситуацию изобрели опцию upgrade, которая обновляет всё, что можно обновить ничего не удаляя. Этим лектор почти не пользуется, гораздо проще сделать dist-upgrade и внимательно почитать, что он хочет сделать. Идеальная ситуация, когда ни один пакет не остается необновленными, а те, которые удаляются, либо замещаются на переименованные, либо на аналогичные по предоставляемой функциональности. Из нечасто встречающихся в практике лектора команд есть ещё
- clean. Как происходит установка из хранилищ? Сначало их надо доставить, лежали там, стали лежать здесь. Сначала вычисляет дерево зависимостей, потом по версиям и дереву вычисляется множество пакетов, которые надо доставить, удалить и так далее, потом они все доставляются в кэш, и потом отдаются рпм. clean оочищает этот кэш.
- reinstall -- слабо документированная фишка. Апт считает что пакет не надо переустанавливать, а вы считаете, что надо. Юзкейз -- надо не переустановить пакет, а зпустить все скрипты, которые запускаются при установке (Например, обновили вы ядро, а оно не взлетает. Тут уж точно поправть конфиги и реинсталл, а то удалять ядро чревато.) Немножко хакерская штука, но она есть и она помогает, когда поломались файли или когда вы ставите пакет ради запуска установочных скриптов.
- apt-cache
- search поиск в описании пакетов. у каждого пакета есть поле description. Именно туда лезет апт, когда говорите apt-cache search. Кроме того смотрит в summary и в именах пакетов. Именно поэтому результаты могут выдавать пакеты, у которых нив названии, ни в кратком описании искомой строки нет, но зато она есть в дескрипшене. Для обычного пользователя необходимость использовать apt-cache заканчивается. Правда, даже это обычно удобней делать через гуи. Ноу у апт-кэша намного больше функций.
- show покажет спецификацию пакета в удобочитаемом виде. Более важная вещь
- depends покажет все пакеты, от которых зависит данный и расскажет почему. Задача апта вычислить дерево зависимостей, поэтому в результате будет многочастный список -- что требуется нашему пакету, и какой пакет провайдит это.
- whatdepends -- какие пакеты зависят от нашего пакета. Всё остальное не так интересно. Есть ещё всякие типа
- pkgnames
- showpkg
- и т. д.
Мы говорили об использовании апта как елси бы у вас список репозиториев прибит гвозядми. Традиционно у апта есть файл /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
Задачи:
- установки, удаление, обновление. rpm -i, rpm - r, rpm -u
- проверка. Отдельный кусок работы с пакетами это проверка их цельности, сотояния установлен или нет и так далее. Это побочный результат той части установщика, которая называется регистрация пакета в системе. rpm -v
- информация. Может взять только из уже имеющего пакета, зато всю подноготную. rpm -q
- сборка. Не так уж далеки и сегодня инструменты по установке и по сборке. rpm -ba (???)
Каждая функция выполняется своим бинарником.
Принцип, по которому апт выбирает тот или иной пакет из равноценных -- трудно предсказать заранее. Соверщенно необязательно самый свежий, и совершенно необязательно тот, который вы думали.
Для сборки.
Необходимо поставить все сборочные зависимости.
рпм глядит в спек, смотрит, удовлеторены ли сборочные зависимости.
Куда это пакет установится? Очень важно понимать, что пакетирование должно подразумевать установку не в корень, а в отдельный каталог, который в альте будет поддиректорией тмп.
Каталог сохранится по результатам вы можете в него поглядеть, посмотреть этапы сборки.
Во всех спеках, которые видел лектор, билдрут удаляется в конце, в альте она не используется. Вообще альтовый спек меньше.
В поле requires написаны далеко не все зависимости, потому что рпм умеет сам находить зависимости. В первую очередь на билиотеки с которыми собран бинарник, но не только.
Еще более велик зазор мужду тем, что написано в provides и что пакет на самом деле провайдит. вписанный руками провайдс встречается довольно редко. Сюда же относится ручной поиск сборочных зависимостей. Выяснилось. что в новом окружении недостаточно написанных в реквайрсах зависимостей.
Проверка рпм после его сборки -- вдруг программа которая хочет какие-то символы, которых нет.
Собрали в пакете библиотеку, которая предоставляет конфликтыне символы. Положили файлы не туда. Всякое бывает. Есть куча способов собрать неправильный пакет. Для этого есть пачка скриптов, которые лежат в \usr\lib\brp.d
Перед тем. как окончательно собрать пакет собираются все скрипты оттуда, чтобы посмотреть, какие пункты полиси вы нарушили. Только после этого генерируется
Чем мы закончили?
Мы сидим, как дураки, выполняем какие-то рецепты. Пора уже начинать собирать пакеты по человечески.