Принцип одного приложения для каждой задачи работает и в подборе консольных программ. Здесь опять не увидеть дублирующих друг друга, например, ftp-клиентов или почтовых программ. А дублирование текстовых редакторов или аудиоплейеров – кажущееся. Так, Vim и nano на самом деле предназначены для решения разных задач работы с текстами, а mpg321 и moc – для разных ситуаций и даже настроения: ведь смысл прослушивания музыки – получение эмоций, ему соответствующих.
Всё это консольное богатство укладывается в чуть больше чем полтысячи пакетов. И занимает на диске 1,1 ГБ.
На мой взгляд, в «стержневой» системе два упущения. Первое – косметическое: по умолчанию не активизирована служба консольной мыши. Хотя пакет gpm присутствует, и это исправляется очень легко.
Второе упущение более существенное: полное отсутствие консольных браузеров. В Salix нет ни links, ни elinks, ни даже канонического lynx. Так что фактически применитель базового варианта этого дистрибутива остаётся без возможности обратиться к сетевым источникам информации. Это упущение должно быть исправлено возможно быстрее, о чём пойдёт речь в главе 5. Но сначала –
Как итог всего сказанного в этой части цикла я приведу сравнение различных вариантов установки Salix с дистрибутивами сходной комплектации, точнее, также с вариантами их установки, с точки зрения занимаемого дискового пространства. В качестве объектов сравнения дистрибутивы, близкие по времени релиза, с которыми я имел дело в последнее время. Это:
• Xubuntu (14.04 Trusty Tahr) как аналог полной установки Salix, поскольку она использует ту же рабочую среду Xfce и сходный набор пользовательских приложений;
• openSUSE 13.1, устанавливаемая с полного DVD (или NET-образа) в варианте Минимальное X Window – он наиболее близок (хотя и не идентичен) базовому варианту Salix;
• Sabayon Spin Base 14.01, более или менее соответствующий «стержневой» инсталляции нашего героя.
Результаты сравнения приведены в таблице.
Таблица 4-1. Сравнение занимаемого дискового пространства разных вариантов Salix и их примерных аналогов
Дистрибутив Объём установки, ГБ Salix FULL 3,1 Xubuntu 3,2 Salix BASIC 1,9 openSUSE, минимальное X Window 2,0 Salix CORE 1,1 Sabayon SpinBase 2,0
Казалось бы, объём дискового пространства при установках Salix в вариантах FULL и BASIC примерно равен таковому его ближайших аналогов, не так ли? Так, да не совсем. При сравнении полной установки Salix и Xubuntu нужно учитывать, что последняя не включает в себя LibreOffice – роль офисного пакета в ней играет сцепка AbiWord и Gnumeric, существенно меньшая по «весу». В openSUSE же с «голой» X Window нет никакой интегрированной рабочей среды – только лёгкий оконный менеджер IceWM. Так что Salix в обоих случаях представляется более компактным. Для консольных же инсталляций Salix и Sabayon эта разница почти двухкратна – и не в пользу последнего.
Три варианта установки Salix предполагают разные модели применения этого дистрибутива. Для варианта FULL это немедленная практическая работа – после, возможно, небольшой косметической доводки. Вариант же BASIC может применяться двояко: как основа для построения системы с собственным рабочим окружением, отличным от Xfce «головного» проекта, или as is – как специализированная рабочая станция, например, для разработки программ.
Однако почти в любом случае инсталляция любого из вариантов потребует некоторой коррекции набора его пакетов, установленного по умолчанию. Так что средствам работы с пакетами будет посвящена глава шестая. Однако сначала я хочу сказать те самые обещанные слова про редакции Salix'а с другими рабочими окружениями, в также про тесно связанный с ним Slackel.
Глава 5. Управление пакетами: slapt-get
В пятой главе сначала дан краткий обзор средства работы с пакетами, применяемыми в дистрибутивах семейства Slackware. Далее описывается утилита slapt-get – основной инструмент для работы с пакетами и репозиториями в дистрибутиве Salix: приведена общая её характеристика, специфические черты и примеры практического применения.
В Salix предусмотрено несколько средств для работы с пакетами,. С одной стороны, в нём имеются базовые утилиты, входящие в пакет pkgtools, унаследованный от Slackware. С другой – в нём могут быть установлены любые средства управления пакетами, когда-либо разрабатывавшиеся для родительского дистрибутива.
Но есть и третья сторона медали – принятые по умолчанию две пары инструментов управления пакетами и их репозиториями:
1. консольная утилита slapt-get и её графическая надстройка Gslapt, предназначенные для работы бинарными пакетами и их репозиториями; дополнительным средством к этой паре выступает служба slapt-update-service, отслеживающая изменения в репозиториях и запускающая по требованию программу Gslapt для обновления установленных пакетов;
2. также консольная программа slapt-src с графической оболочкой Sourcery – та и другая обеспечивают автоматизацию сборки пакетов из их исходных текстов с помощью специальных сценариев, так называемых слакбилдов (slackbuilds).
Три из этих четырёх инструментов, slapt-get, Gslapt и slapt-src не уникальны для Salix'а. Они были разработаны Язоном Вудвардом (Jason Woodward) для первозданной Slackware ещё в 2003-2005 годах, и с тех пор время от времени использовались как в ней самой, так и в ряде происходящих от неё дистрибутивов (например, в Vector Linux). Однако в состав официального дистрибутива она не была включена. Авторство же Sourcery принадлежит Жоржу Влахавасу — инициатору проекта Salix. И именно в этом дистрибутиве они были объединены «в одной коробке» и возведены в ранг основного инструментария для управления пакетами. Чем во многом и определилась специфика Salix.
Управление пакетами: обзор
Впервой главе говорилось о сохранении совместимости Salix с оригинальной Slackware. Это касается и средств управления пакетами. Поэтому свой рассказ я начну с их обзора в прародительском дистрибутиве.
Сначала – несколько слов о формате пакетов. В Slackware и всех её клонах он предельно прост, представляя собой скомпилированные бинарные файлы «авторского» пакета (то есть созданного его разработчиком), собранные в архив утилитой tar, сжатый компрессором xz (современный суффикс файлов пакетов – txz). К этому добавляется описание пакета и, обычно, пред- и постинсталляционные сценарии. Однако никакой информации о зависимостях пакета в нём самом не содержится.
Базовые средства Slackware для работы с пакетами собраны в пакете (смайлики по вкусу) pkgtools. Он предназначен для работы с единичными пакетами или их сериями и объединяет следующие утилиты:
• installpkg – установка пакета;
• upgradepkg – обновление пакета;
• removepkg – удаление пакета;
• explodepkg – развёртывание пакета как архива;
• makepkg – создание пакета.
Все они требуют указания аргумента в виде имени пакета (или группы пакетов, а первые три – ещё и прав администратора для своего выполнения.
Кроме того, имеется pkgtool — интегрирующая меню-ориентированная оболочка для установки, удаления и просмотра пакетов и их серий. Она имеет текстовый интерфейс на базе ncurces. Для запуска её обязательно требуются права суперпользователя
$ sudo pkgtool
В аргументах эта команда не нуждается, так как предполагает работу в интерактивном режиме.
Рисунок 5-1. Интерфейс утилиты pkgtool
Все утилиты работают напрямую с пакетами Slackware, которые, как уже сказано, информации о зависимостях не содержат. И потому они тоже никак зависимости не отслеживают – то есть не только не пытаются их разрешить, но даже не сообщают о нарушениях. То есть любой пакет будет установлен в любом случае, но если в системе отсутствуют пакеты, с которыми он связан жёсткими зависимостями (например, нужные для него библиотеки), то работать он просто откажется. Аналогично и с удалением пакетов: removepkg позволяет удалить библиотеки, от которых зависят другие пакеты системы – с вполне предсказуемым результатом.
Другая особенность инструментария pkgtools – его локальный характер, для работы с репозиториями он изначально не предназначался. Максимум, на что способны его утилиты – установление серий пакетов или пакетов из определённого каталога.
Казалось бы, по своим функциям инструменты pkgtools ничем не отличаются от связки обычного архиватора и декомпрессора сжатых файлов. Но это не так. Потому что они выполняют самую важную обязанность любого средства управления пакетами – их фиксацию в базе данных, что позволяет поддерживать систему в целостном состоянии, не превращая в свалку бинарников.
