Алексей Федорчук. Книга о FOSS, Unix, Linux, BSD, Solaris и свободных программах для них
Для дистрибутивных пакетов существует несколько видов распространения или, как принято говорить, форматов пакетов. Одни из них (rpm или deb) получили широкое распространение за пределами материнских систем, другие используются только в “родных” дистрибутивах, третьи же достаточно объединяются в группы достаточно условно. Читать дальше »
Системиа управления пакетами Synaptic — графический фронт-энд для утилит семейства apt (Advanced Packaging Tool), обычно используемыми для работы с пакетами deb-формата, но частично могущими быть прикрученными и к пакетам rpm. Читать дальше »
Как уже говорилось, Synaptic — это интегрирующая надстройка над утилитами семейства apt, и предоставляет все функции, обеспечиваемые командами apt-get и apt-cache, а именно: Читать дальше »
Ознакомившись в общих чертах с видом и нравом Synaptic’а, пора перейти к его практическому использованию. Однако использование любой программы целесообразно начать с её настройки. Начнём с этого и мы. Читать дальше »
Покончив с настройками Synaptic’а, можно, наконец перейти к приёмам его практического использования. Читать дальше »
Формат пакетов (deb) дистрибутива Debian, как и основанные на нём средства пакетного менеджмента — в числе выдающихся достижений его разработчиков, унаследованное всеми Debian-клонами и дериватами. Во многом именно они и предопределили успех производных от него дистрибутивов, в том числе и тех, которые, как Ubuntu, популярностью превзошли родителя. Читать дальше »
Дистрибутив Debian GNU/Linux давно и по праву славится своей системой управления пакетами. Успех которой слагается из трех компонентов:
Потомки Debian, такие, как MEPIS, Xandros, Linspire, вместе с форматом пакетов унаследовали от прародителя и все остальные составляющие удачливого пакетного менеджмента. B, конечно же, все они характерны и для самого популярного деривата Debian — семейства дистрибутивов Ubuntu, каковое и будет предметом дальнейшего рассмотрения.
Ниже будет рассмотрено устройство репозиториев Ubuntu, что преследует две цели. Первой является чисто удовлетворение собственного любопытства — дабы поглядеть, как оно устроено “внутре”. Но есть и цель практическая: каким образом можно получать информацию о пакетах с машины, не имеющей подключения к Сети — согласитесь, в нашей умеренно интернетизированной СНГовии задача достаточно актуальная.
Сразу следует оговориться, что без физического доступа к Сети вообще использование средств пакетного менеджмента Debian может носить предельно ограниченный характер, распространяясь только на репозитории с “твердых” носителей, типа дистрибутивных компактов. Нет, речь идет все-таки о случае, когда какой-никакой доступ к Сети все-таки имеется, только не с той машины и, возможно, не с той платформы, на которой Ubuntu используется (например, со служебной машины под управлением Windows).
Сначала — пара слов о репозиториях Ubuntu вообще. Официальные репозитории Ubuntu — общие для всех дистрибутивов семейства, и располагаются они
и так далее. Кроме официального репозитория, имеются также репозитории, так сказать, полуофициальные. Для пользователей Kubuntu, например, важнейшим из них будет
Чтобы получить представление о внутреннем устройстве репозитория Ubuntu, посетим одно из его зекрал, например, . Внутре него видим файл ls-lR.gz (представляющих собой полный список всего файлового дерева репозитория, с атрибутами принадлежности, доступа, и так далее), а также следующие каталоги:
dists/indices/pool/project/Назначение каталога project/ показалось мне не вполне понятным, каталог indices/ содержит нечто вроде списков файлов, в каталоге dists/ описываются всякого рода сведения о пакетах, а сами они имеют место быть в каталоге pool/. Собственно, два последних каталога нас и будут интересовать.
Начнем с описания пакетов, то есть содержимого каталога dists/. Надо сказать, что классификация пакетов в Ubuntu выглядит еще более запутанной, чем в Debian’е, где она тоже не являет собой эталон прозрачности.
В первом приближении пакеты классифицируются по именам релизов — на текущий момент актуальны релизы Dapper (6.06, точнее, ее bugfix-редакция 6.06.1), которому обещана пятилетняя поддержка, Edgy (6.10) — последний по времени стабильный релиз, и Feisty (будущий 7.04) — то, что станет релизом весной 2007 года (если полугодовой цикл разработки не будет нарушен). Но описания всех предыдущих релизов Ubuntu также имеются в каталоге dists/, образуя самостоятельные подкаталоги. В качестве исторической справки напомню, что это были Breezy (5.10) и Hoary (5.04). Лишь следов самой первой версии, Warty (4.10) не удается найти в репозитории.
Далее, в каждом релизе, помимо основного массива пакетов, выделяются еще и так называемые категории — каждой из них соответствует подкаталог того же уровня, что и подкаталог релиза, а именуются они так (на примере релиза edgy):
edgy-backports/edgy-proposed/edgy-security/edgy-updates/Категория backport включает пакеты, не входящие в основной комплект дистрибутива, не столь оттестированные, как последние, но которые могут содержать всякие новые версии с полезными фичами.
Категория security, как можно догадаться из названия, содержит обновления, направленные на повышение безопасности.
Категория proposed содержит тестируемые обновления пакетов, которые со временем, надо полагать, переходят в категорию updates. Впрочем, я могу и ошибаться — однако для целей нашего рассмотрения все категории, за исключением backports, не очень существенны.
Внутри каждого релизного и категорийного подкаталога, в свою очередь,имеются наборы подкаталогов, соответствующих группам пакетов — т.н. компонентам дистрибутива:
main/restricted/universe/multiverse/А уже внутри них — каталоги для описания бинарных пакетов, собранных под каждую из поддерживаемых архитектур:
binary-amd64/binary-i386/binary-powerpc/binary-sparc/каталог писания пакетов исходников
source/
каталог с переводами описаний
i18n
Каждый каталог содержит три файла: Release — файл с общей информацией о ветке репозитория, Packages.gz и Packages.bz2, которые на самом деле представляют собой один и тот же файл Packages, сжатый утилитами gzip и bzip2, соответственно. Файл Release, как явствует из его названия, представляет собой общее описание компонента данного релиза, и выглядит примерно так:
Archive: edgy Version: 6.10 Component: main Origin: Ubuntu Label: Ubuntu Architecture: amd64
Содержание же файл Packages — полный список пакетов данного компонента и архитектуры. Для каждого пакета из этого списка приводятся:
То есть здесь мы видим нечто вроде аккумулятивной суммы файлов control для всех пакетов репозитория, с единственным добавлением строки Filename, описывающей путь к данному пакету именно в данном репозитории.
Картина получается достаточно запутанная. Но в ней важны два момента. Первый — не смотря на иерархический вид подкаталогов внутри dists/, классификация эта на самом деле не иерархическая, а проведена по трем независимым признакам — категории, компоненту и архитектуре. И второй момент — это в сущности классификация не пакетов, а только их описаний, то есть метаинформации о пакетах. И пользователю с ней общаться практически не приходится — она используется утилитами семейства apt или программой aptitude для извлечения (установки, вывода информации и так далее) о требуемых в данной ситуации пакетах — нужного компонента и нужной архитектуры.
Классификация же собственно пакетов, с которой только и сталкивается пользователь (да и то не совсем вплотную), гораздо проще, в чем можно убедиться при рассмотрении подкаталога pool/ (то есть “пула” пакетов). Здесь мы видим всего четыре подкаталога, соответствующие указанным выше компонетам дистрибутива:
main/restricted/universe/multiverse/Компоненты группируются следующим образом:
main — полностью свободные пакеты, официально поддерживаемые разработчиками Ubuntu;restricted — пакеты, также официально поддерживаемые дистрибутивом, но не вполне свободные;universe — полностью свободные программы, официально дистрибутивом не поддерживаемые и развивающиеся силами независимых разработчиков;multiverse — пакеты, аналогично universe официально не поддерживаемые и не вполне свободно распространяемые.Понимание свободно распространяемых программ с точки зрения лицензии Ubuntu примерно соответствует принципам свободного программного обеспечения Debian, которое, в свою очередь, весьма сходно с пониманием свободного софта FSF. Пакеты из компонентов restricted и multiverse имеют разного рода ограничения на распространение в некоторых странах или могут содержать закрытые части. Примерами являются фирменные драйверы для видеокарт Nvidia (restricted) или мультимедиа-кодеки, использующие патентованные в отдельных странах алгоритмы (multiverse).
Каждый из компонентных каталогов разбит на “алфавитные” подкаталоги — от a до z. Исключение — библиотечные пакеты, сгруппированные в подкаталоги вида liba — libz. Внутри “алфавитных” подкаталогов имеются подкаталоги пакетные, а в них уже лежат отдельные deb-пакеты, представляющие собой конкретные сборки под определенные архитектуры.
Итак, состав предлагаемых репозиторием определённому дистрибутиву пакетов можно получить из файла url/dists/release_name/component/type/Packages, где url — url репозитория (в нашем случае — http://ru.archive.ubuntu.com/ubuntu/), release_name — имя релиза (в данном случае edgy), component — наименование компонента (main | restricted | universe | multiverse), type — тип пакета (binary | source), отражающий для бинарников ещё и архитектуру (binary-amd64, binary-powerpc).
Сколько компонентов и их типов предполагается использовать — столько потребуется и файлов Packages. Файлы эти, как было показано выше, легко читаемы, размер их сравнительно невелик. Так, для Ubuntu Edgy он составляет по 1,2 Мбайт (*.gz) или по 900 Кбайт (*.bz2) на каждый тип компонента main. Packages-файлы компонентов restricted и multiverse вообще не чувствительны (примерно по 5 и 100 килобайт). Наибольший “вес” дают типы компонента universe (3-4 Мбайт, в зависимости от компрессора), но и это не смертельно даже при модемном соединении.
Так вот, скачав где-либо нужные файлы Packages, перенеся их на целевую машину и поместив в каталог /var/lib/apt/lists, можно в даже при отсутствии Сети на ней, получить полную информацию о пакетах, предлагаемых репозиторием. Причем они будут доступны для любых программ управления deb-пакетами — утилит системы apt, aptitude, Synaptic (Ubuntu и Xubuntu) или Adept (Kubuntu).
Если скачать ещё и url/dists/your_distr/Release* — apt-утилиты перестанут “ругаться” по поводу “непроверенности” предлагаемых пакетов.
Названия файлов формируются просто, как “правда”: url_dists_yourdistr_component_type_Packages. То есть, например:
au.archive.ubuntu.com_ubuntu_dists_dapper_main_binary-i386_Packages.
Так, в отсутствие Сети, можно познакомиться с тем, чтобы мы могли получить от того или иного репозитория, если бы Сеть была.
Все сказанное выше относилось к официальным репозиториям Ubuntu. Устройство репозиториев полу-официальных и совсем неофициальных может несколько отличаться в деталях. Причем “единство стиля” не всегда выдерживается даже внутри одного и того же репозитория. Например, в репозитории Kubuntu можно видеть дерево каталогов, где причудливо перемешаны подкаталоги отдельных пакетов различных версий (например, amarok), пакетных комплексов типа kde и koffice, их же для определенного релиза (например, hoary-kde341/ и так далее, hoary-koffice14/). Впрочем, это относится к ранним стадиям формирования репозитория. Ныне его структура устоялась, и каталоги последних версий amarok, kde и koffice включат, как правило, подкаталог dists и отдельные подкаталоги для сборок под определенный релиз. Например, в состав каталога kde355 входят пулы сборок для Dapper и Edgy:
pool-dapper/ pool-edgy/
и так далее. Как сконструировать из них имена Packages-файлов — предоставляется читателю в качестве самостоятельного упражнения.
Все предыдущее изложение исходило из молчаливого допущения отсутствия подключения к Сети на целевой машине. Однако по настоящему эффективное использование средств пакетного менеджмента Debian (и, соответственно, Ubuntu) достигается в онлайновом режиме.
Первое, что требуется для использования мощи средств цправления deb-пакетами — это настройки доступа к их репозиториям. Ниже этот вопрос рассмотрен на примере дистрибутивов Ubuntu и Kubuntu — пакетные репозитории едины для всего семейства. Читать дальше »
В отношении средств управления пакетами в Debian и его клонах имеется богатый выбор:
dpkg, предназначенная для установки, конфигурирования и удаления единичных пакетов, обеспечивающая проверку зависимостей, но не имеющая собственных средств их разрешения (см. подробности);dselect — front-end (оболочка) для dpkg, работающая в текстовом режиме; обеспечивает не только установку/удаление программ, но и групповой выбор пакетов по целевому назначению, а также разрешение зависимостей между ними; считается устаревшей, сохраняется как реликт и далее рассматриваться не будет;apt — универсальный набор инструментов командной строки для управления deb-пакетами, включая разрешение зависимостей между ними, а также построение из исходников отдельных пакетов и тотальную пересборку установленной системы с заданными параметрами компиляции (описан здесь);aptitude — основана на тех же библиотеках: что и apt, обеспечивая большинство его функцй, но не является его прямым фронт-эндом; предусматривает как командный, так и интерактивный режимы работы (описан здесь);Synaptic — кросс-пакетный графический фронт-энд для утилит семейства apt, обеспечивающий практически идентичную с aptitude функциональность; подробно рассмотрен в отдельной подрубрике.Все эти средства унаследованы от прародителя — Debian’а его клонами. Которые, однако, могут включать в себя и собственный инструментарий пакетного менеджмента. Так, в Kubuntu до поределённого времени имелся собственный менеджер пакетов - Adept, предназначенный для работы в графической среде KDE. Это была весьма интересная программа, но до ума её так и не довели. Ныне в Kubuntu штатно используется кросс-платформенный менеджер пакетов PackageKit в лице его графического фронт-энда — kpackagekit.
Остальные средства работы с deb-пакетами будут рассмотрены в данной подрубрике.
На фоне своих блистательных сородичей — семейства apt-get и программы aptitude, - утилиты dpkg, предназначенные для работы с единичными deb-пакетами, выглядят весьма скромно. Однако они Читать дальше »
Для начала рассмотрим установку пакетов. Если нам необходимо установить единичный пакет, поступаем так: Читать дальше »
Следующая сфера деятельности команд семейства dpkg — получение информации о пакетах. Для уже установленных пакетов это проще всего сделать с помощью команды dpkg-query, требующей указания какого-либо из операторов действия и имени пакета в качестве аргумента. Читать дальше »
Еще одна важная задача утилит dpkg — выполнение настройки отдельных, уже установленных, пакетов. Предназначенная для этого команда так и называется — dpkg-reconfigure, и запускается (от лица суперпользователя или посредством команды sudo) таким образом:
$ dpkg-reconfigure packagename
После этого вызывается диалоговая программа конфигурации — debconf, и ответы на серию более или менее тривиальных вопросов позволяют добиться желаемого результата. Каковы эти вопросы — зависит от настраиваемой программы. Чтобы получить представление о процессе, рассмотрим пример с реконфигурированием кириллического окружения в консоли, за которое отвечает пакет console-cyrillic (разумеется, перед настройкой он должен быть установлен). Правда, и без него консоль и в Debian, и во всех представителях семейства Ubuntu русифицирована вполне справно, но использование console-cyrillic позволяет использовать многие дополнительные возможности по сравнению с базовой кириллизацией.
Итак, в ответ на команду
$ dpkg-reconfigure console-cyrillic
последовательно вызывается серия диалоговых окон. Первое из них предлагает ввести список используемых (и нуждающихся в русификации) виртуальных терминалов, каковых по умолчанию шесть (и с умолчаниями вполне можно согласиться).
Далее идет выбор раскладки: и здесь придётся придерживаться умолчального выбора — Русская с Win клавишами, как будто других на просторах Руси и не осталось.
Затем предлагается определить переключатель латиница/кириллица. Им может быть традиционный CapsLock, но — не тюрьма же народов! — выбор достаточно обширен, включая не только традиционный “подоконный” Alt+Shift, но даже и Win-клавиши (действительно, надо же прикрутить к ним хоть что-нибудь).
Следующая панель выбора — назначение временного переключателя между кириллической и латинской раскладками клавиатуры, действующего только на набор следующего символа (типичное его применение — ввести столь любимый соотечественниками символа бакса в русскоязычный текст).
После этого предлагается выбрать экранный шрифт. Их немало, но при локали UTF-8 всерьез следует рассматривать только Terminus Unicode жирный или Terminus Unicode Framebuffer — в зависимости от того, используется ли графическая консоль через линейный кадровый буфер, или нет.
С размером матрицы шрифта также вопросов не возникает — в современных условиях приемлема только матрица 8×16.
“И, наконец, — как говорит очередная информационная панель, — вам нужно выбрать используемую кодировку”. Поскольку мы не живем ни в Сербии, ни в Македонии, и веяниям прогресса также не чужды, останавливаемся на UNICODE.
Последний вопрос — установить ли настройку кириллицы в консоли при старте системы. С чем, очевидно, следует согласиться — иначе за каким таким зеленым все проделывалось? В любом случае — на этом реконфигурирование заканчивается, и возвращается приглашение командной строки.
Примерно так же выглядят диалоги при настройке любого пакета, в принципе предусматривающего реконфигурирование.
Назначение команды apt-cache — в получении информации о пакетах, как установленных на локальной машине, так и находящихся в сетевых репозиториях. Причем в последнем случае она извлекается даже при запуске на локальной машине, не обязательно подключенной к сети (хотя в целом без сети использование ее ограничено). Читать дальше »
Вот теперь можно взяться и за отдельные пакеты. Весь вопрос в том — за какие именно? Ведь дистрибутивные deb-пакеты вовсе не совпадают с пакетами авторскими — они намного более дробные. Например, каждый из авторских пакетов KDE, типа kdenetworks или kdegraphics, делится на множество мелких монофункциональных deb-пакетов. Хорошо, если пользователь наизусть знает те компоненты, которые ему необходимы — и именно в варианте пакетирования Ubuntu/Kubuntu (совпадающем с пакетированием Debian). А если нет? Читать дальше »
Выше я упоминал об операторе source, предназначенном для работы с пакетами исходников. И он вполне оправдывает себя, если речь идет о сборке единичных пакетов. Если же нужно собрать много пакетов, пересобрать систему целиком или требуется компиляция с какими-либо особыми условиями, лучше прибегнуть к специализированному инструменту — apt-build. Читать дальше »
Программа aptitude была создана в 1999 году в качестве замены dselect — архаичной и не удобной в использовании надстройки над утилитами dpkg. Впервые она была включена в Debian 2.2 ( так называемый potato), и с тех пор утвердилась в этом дистрибутиве в качестве штатного средства управления пакетами. Читать дальше »