Linux Mint и его Cinnamon. Очерки применителя. Часть 5

Алексей Федорчук aka Alv

Все дистрибутивы Linux, и Mint тут не исключение, организованы по пакетному принципу. Точно также, в виде пакетов, распространяются и любые дополнительные программы для них, создаваемые независимыми разработчиками. И потому одна из важных задач пользователя — это интеграция пакетов в свою систему. Она решается средствам управления пакетами, предназначенным для установки, обновления и удаления программ, учета и разрешения их зависимостей. Однако, прежде чем говорить о таких средствах, не худо посмотреть, что такое пакеты вообще, deb-пакеты в частности и пакеты дистрибутива Mint в особенности. А также — каким образом они организованы в репозитории.

Пакеты, зависимости, библиотеки

Пакеты — это своего рода программные кванты, на которые делится система или дистрибутив. Это могут быть и простые монофункциональные утилиты (например, строчный текстовый редактор ed или архиватор tar), более или менее обширные наборы функционально связанных программ (скажем, coreutils) или составные части огромных программных комплексов (примером чему — Cinnamon, о котором столько гворилось в прошлых очерках).

Термин пакет (английское package) употребляется в двух смыслах: как авторский набор исходных текстов, созданный разработчиком программы, и как комплект скомпилированных из него исполняемых программ и всех их служебных файлов, собранный майнтайнерами дистрибутива или вообще третьими лицами. Пакеты в первом смысле называются исходниками или вообще «сырцами» (от ангийского Source), во втором — бинарниками. Далее в этой книге речь пойдёт почти исключительно о пакетах во втором понимании этого термина.

Бинарные пакеты специфичны для семейств некогда родственных дистрибутивов, почему часто говорят о системах rpm based или deb based. Но даже если они собраны в одном формате (например, rpm или deb), бинарные пакеты из разных дистрибутивов далеко не всегда совместимы в рамках одной системы. Впрочем, к формату deb, принятому в дистрибутиве Mint и потому в интересующему нас больше всех остальных, вместе взятых, это относится в наименьшей степени: его пакеты сохраняют почти полную бинарную совместимость с пакетами родительской Ubuntu и частичную — с пакетами прародительского Debian’а.

Ключевым для бинарных, или дистрибутивных, пакетов является понятие зависимостей. Суть его в том, что пакет packagename1 для сборки, установки и (или) функционирования требует наличия в системе пакета packagename2, тот, в свою очередь, может потребовать пакета packagename3, и так далее.

Выделяются разные типы зависимостей. С одной стороны, различают зависимости при сборке (обычно называемые просто зависимостями — depends) и зависимости при запуске (по английски именуемые run depends).

Как следует из названий, теоретически зависимости первого рода необходимы только на стадии сборки пакета, тогда как зависимости второго рода действуют постоянно. На практике же в большинстве случаев depends и run depends если и не эквивалентны, то значительно перекрывают друг друга.

С другой стороны, следует различать зависимости жёсткие и «мягкие». Удовлетворение первых абсолютно необходимо для сборки и функционирования данного пакета. Так, практически любая программа использует главную системную библиотеку glibc (или libc), любое приложение для системы X — одну из главных Иксовых библиотек: старые — xlib, новые — xcb, любая интегрированная рабочая среда — одно из двух основных семейств высокоуровневых библиотек, Qt/kdelibs или Gtk.

«Мягкие» зависимости данного пакета не критичны для его функционирования — удовлетворение их лишь добавляет ему дополнительные функции (например, печати и сканирования для офисных и графических приложений) или возможности (скажем, доступ к файлам данных определённых форматов для той же графики или мультимедиа).

В deb-формате бинарных пакетов предусмотрено более дробное разделение «мягких» зависимостей, но об этом подробнее будет шговориться чуть позже. А пока замечу, что часто приходится учитывать и так называемые конфликтующие зависимости — то есть альтернативные по назначению пакеты, не способные ужиться в одной системе.

Понятие зависимостей пронизывает насквозь UNIX-совместимые системы, и особенно важно для свободных их представителей. В то же время пользователи Windows с ним сталкиваются очень редко, и потому постижение его вызывает у них определённые трудности.

Традиционная модель разработки UNIX-программ (то, что задумчиво именуют UNIX Way) характеризуется ярко выраженным стремлением не множить сущности без крайней необходимости. Или, говоря попросту, не изобретать велосипеды. То есть: если требуемая разработчику данной программы функция уже реализована и включена в какую-либо распространенную библиотеку, то наш разработчик скорее всего этой библиотекой и воспользуется, а не будет переписывать ее с нуля. Благо, поскольку все распространённые и общеупотребимые библиотеки открыты, он имеет полную возможность это сделать.

Ведь все программы, вне зависимости от их назначения, неизбежно должны выполнять некоторые однотипные действия, как то: открыть файл, записать его, вывести на экран его содержимое, и так далее, вплоть до закрытия. Сущность таких действий не меняется, что бы программа ни делала. И потому нет никакого смысла программировать такие манипуляции каждый раз заново.

Вот их, как правило, поддаваясь смертному греху лености, и не программируют «с нуля». А объединяют соответствующие директивы в отдельные программные комплексы, именуемые библиотеками (libraries). Сами по себе они к автономному исполнению не пригодны. Однако любая программа, при необходимости совершить одно из типовых действий, вызывает из такой библиотеки некий фрагмент кода, содержащий требуемую последовательность директив.

Библиотеки обычно привязаны к определённым языкам программирования, синтаксису которого подчиняются описания директив, так называемых функции. Поскольку наиболее употребимым в UNIX-системах и их приложениях является язык C, то его функции и требуются чаще всего. Они собираются в главную системную библиотеку, которая почти во всех дистрибутивах Linux именуется glibc.

Однако главной системной библиотекой список не исчерпывается. В UNIX-подобных системах при создании пользовательских интерфейсов используются библиотеки свойств терминала (например, ncurces) для консольных программ и библиотеки, описывающие процедуры отрисовки окон и управления ими — для графических программ системы X, библиотеки интерфейсных элементов и графических примитивов более высокого уровня (Motif, Qt, Gtk), библиотеки описания графических и мультимедийных форматов файлов и тому подобные «сборники». Иными словами, существует тенденция к вынесению в разделяемые библиотеки всех повторяющихся действий и элементов, какие только возможно.

Если библиотек, используемых в программах для консольного режима, не так много, они достаточно универсальны и легко поддаются учёту, то с библиотеками для обеспечения графического режима существенно сложнее. Даже простое перечисление их заняло бы немало места. Поэтому ограничусь констатацией факта, существенного для нашей темы. Обе основные рабочие среды дистрибутива Mint, MATE и Cinnamon, а также шататные приложения обеих редакций базируются на библиотеках Gtk — 2-й и 3-й версий, соответственно. К ним же примыкает и «левая» редакция с Xfce. И лишь KDE-редакция Mint основывается на библиотеках Qt и kdelibs. Поскольку основной героиней этого романа является Cinnamon, то дальше речь пойдёт в основном о пакетах, связанных зависимостями с библиотекой Gtk 3.

Mint: формат пакетов

Как уже было сказано, в дистрибутиве Mint принят deb-формат пакетов. Будучи разработан ещё в прошлом тысячелетии для дистрибутива Debian, формат этот был унаследован от него Ubuntu, во многом предопределив успех последней. А вслед за ней — и удачливость нашего главного героя. Почему deb-формату и следует уделить некоторое внимание.

Пакет deb-формата — архивный файл (собранный утилитой ar, о которой недавно шла речь), включающий три комопнента. Первый — это файлик debian-binary, не содержащий ничего, кроме номера версии deb-формата (в данный момент — 2.0).

Второй файл носит имя data.tar.xz и, как легко догадаться, представляет собой tar-архив, сжатый утилитой xz. Содержимое архива — скомпилированные исполняемые бинарники и необходимые им для работы компоненты (библиотеки, конфиги, документация и так далее). Иными словами, все компоненты, которые при установке пакета будут инкопропрированы в файловую иерархию целевой системы. Например, для пакета cinnamon_2.4.1+rebecca_amd64.deb в этом архиве обнаруживается каталог /usr с подкаталогами /usr/bin, /usr/lib, /usr/share, содержащими исполняемые бинарники, библиотеки и разделяемые компоененты, соответственно.

Третий файл именуется control.tar.gz и представляет собой архив файлов, содержащих всякого рода метаинформацию — описание пакета, его зависимости, классификационную принадлежность, приоритет и так далее (файл control), контрольные суммы всех исполняемых бинаников (файл md5sums), сценарии, выполняемые при установке и удалении пакета (preinst, postinst, prerm и postrm).

Зависимости в терминах deb-пакетов имеют несколько градаций: обязательные (depends), рекомендуемые (recommends), предлагаемые (suggests), конфликтующие (conflicts). Первая градация — это обычные “жесткие” зависимости, без удовлетворения которых пакет либо не будет работать, либо вообще не установится. С градацией последней тоже понятно — это, так сказать, анти-зависимости: например, Opera текущей, 26-й, версии конфликтует с пакетов opera-12.16.

Ну а зависимотси рекомендуемые и предлагаемые — это две разновидности “мягких” зависимостей. Разница между ними в том, что рекомендуемые пакеты обеспечивают «зависимому» пакету дополнительные функции (например, поддержку мыши в консольных приложениях), а пакеты предлагаемые предоставляют дополнительные возможности, вполне вероятно, полезные, но не жизненно необходимые (например, документацию, в том числе на не-английских языках). То есть первая категория как бы более нужная, нежели вторая. Впрочем, таково субъективное мнение майнтайнера конкретного пакета — вполне возможно, что у применителя будет своё мнение по этому поводу. И потому и пакетный менеджер apt, и его графическая «морда» Synaptic, устанавливающие зависимости автоматически, в Mint по умолчанию не делают этого ни для рекомендуемых, ни, тем более, для предлагаемых пакетов, а лишь выводят их список, дабы применитель сам принял решение по данному вопросу.

Кроме того, спецификой deb-пакетов является еще и существование так называех пред-зависимостей (pre-depends) — при их нарушении установка пакета даже не может начаться, ибо их наличия требует пре-инсталляционный сценарий «зависящего» пакета. Впрочем, с точки зрения пользователя они немногим отличаются от обычных зависимостей типа depends.

Кроме зависимостей, для пакетов deb-формата важно также понятие их приоритета. Оно отражает степень необходимости пакета для функционирования системы, например: обязательный (required), без которого работа системы невозможна, основной (base) и важный (important), также оказывающиеся практически необходимыми, стандартный, то есть имеющийся практически в любой полнофункциональной Linux-системе, дополнительный (optional) — тут уж степень важности каждый должен решать для себя.

Как это принято в мире Open Source, все бинарные пакеты Mint (а также, конечно, Ubuntu и сородичей) сопровождаются исходными текстами, доступными из соответствующего репозитория дистрибутива. И здесь deb-формат проявляет свою специфику: каждый пакет в исходниках обычно включает три файла — packagename.orig.tar.gz, packagename.dsc и packagename.diff.gz.

Первый — самый обычный тарбалл исходных текстов авторского пакета, что подчеркивается словом orig в его имени: формат архива, имя и система нумерации версий также совпадают с таковыми авторского пакета. Файл packagename.dsc содержит в себе всю метаинформацию, необходимую для правильного построения из него бинарного deb-пакета. А packagename.diff.gz — это те изменения исходного кода, которые вносятся для адаптации пакета непосредственно к данному дистрибутиву. Если таких изменений не потребовалось (или если пакет писался именно для Ubuntu или Mint), он может и отсутствовать.

Репозитории: введение

Пакеты, входящие в дистрибутив (или, если угодно, образующие дистрибутив), валяются не абы как — они организованы в репозитории. Что это такое?

В переводе на русский язык слово репозиторий означает хранилище — и именно его рекомендуют употреблять языковые пуристы (они же те, кто предпочитает называть себя grammar nazi). Однако, как это обычно бывает по жизни, в народе утвердилось иное их именование — repo или, говоря по нашему, по бразильскому кириллическому, репы. Почему во множественном числе — станет понятно из дальнейшего рассказа.

Сам по себе репозиторий действительно можно в первом приближении определить как место хранения пакетов, специально собранных для данного дистрибутива, к которому возможен свободный (мы ведь ведём речь только о свободных системах) доступ.

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

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

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

В последние годы получила распространение точка зрения, что право на гордое имя настоящего дистрибутива даёт только собственный репозиторий пакетов, при его отсутствии ты в лучшем случае ремикс дрожащая, а то и вообще жалкий респин. Причём дистрибутив, претендующий на всенародную любовь, обязан иметь репозиторий тем более всеобъемлющий, чем шире его претензии.

Автор этих строк и сам активно поддерживает озвученный взгляд. Однако Mint, казалось бы, служит живым его опровержением. Ибо в базовой своей части, начиная с ядра и заканчивая Xorg, он не просто основывается на репозиториях Ubuntu, подобно тому, как последняя основывается на репозиториях Debian ветки testing. Нет, Mint просто напрямую использует соответствующие пакеты из официального репозитория Ubuntu, без всяких модификаций, патчей, пересборок и тому подобных архитектурных излишеств. Нет, Mint, конечно, имеет и собственный репозиторий, но он выглядит песчинкой по сравнению с глыбой репозиториев прародительской системы.

И, тем не менее в звании дистрибутива Mint никто и никогда даже не пытался отказывать. Почему? Да потому, что репозиторий его, что называется, мад, да удал: в нём поддерживаются пакеты, определяющие своеобразие дистрибутива, такие, как «фирменные» утилиты, рабочие среды Cinnamon и MATE. Причём если для MATE репозиторий Mint является как бы вторичным по отношению к «головному» репозиторию проекта mate-desktop.org, то соответствующий репозиторий Cinnamon выступает самым что ни на есть «головным» для этой среды и всех связанных с ней пакетов (вроде файлового менеджера Nemo). И, само собой, таковым он является и для всех дистрибутив-специфичных пакетов — дисплейного менеджера MDM и комплекса Mint-утилит. Ну а что разработчики Mint не занимаются пересборкой базовых пакетов из репозиториев Ubuntu — вполне понятно: зачем изобретать велосипед, когда имеющийся вполне пригоден для езды. Это позволяет сконцентрировать силы на развитии «генеральной линии» собственной системы.

Пояснение: под «головным» репозиторием я понимаю то, что на вражьей мове называется upstream: они поддерживаются основной командой данного пакета или комплекса пакетов, в них хранятся исходники их текущих и разрабатываемых версий, туда же вливаются (или, по крайней мере, должны вливаться) патчи от независимых разработчиков. И на них основываются сборки бинарных пакетов для всех дистрибутивов, испытывающих необходимость в оных.

В ближайших разделах будет последовательно рассмотрено устройство базового репозитория Ubuntu, а затем собственного репозитория Mint. Кроме этих официальных репозиториев, в Mint могут быть использованы пакеты из PPA-репозиториев Ubuntu, собираемые для этого дистрибутива независимыми майнтайнерами. Так что и них будет сказано под занавес.

Устройство репозиториев Ubuntu

Официальные репозитории Ubuntu располагаются по адресу: archive.ubuntu.com/ubuntu. Это — «головное» хранилище пакетов, имеющее многочисленные региональные зеркала, принадлежность которых к стране указывается стандартным двухсимвольным префиксом, например ru.archive.ubuntu.com/ubuntu/ — российское зеркало. Впрочем, как раз российского зеркала утилита Mintsources (о которой шла речь в соответствующем разделе) автоматически не предлагает.

Проще всего с устройством репозиториев с точки зрения применителя можно ознакомиться просмотром их списка в файле /etc/apt/sources.list.d/official-package-repositories.list. Он создаётся автоматически при инсталляции, но затем может быть изменён с помощью Mintsources или отредактирован в текстовом редакторе. Например, у меня относящесяся к репозиториям Ubuntu строки имеют следующий вид:

deb http://gd.tuwien.ac.at/opsys/linux/ubuntu/archive trusty main restricted universe multiverse
deb http://gd.tuwien.ac.at/opsys/linux/ubuntu/archive trusty-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu/ trusty-security main restricted universe multiverse

Здесь первый компонент в каждой строке, deb, означает, что речь идёт о бинарных пакетах (про пакеты с исходниками я скажу чуть позже). Далее следует «базовый» URL репозитория. В первых двух строках он соответствует тому серверу, который был выбран мной с помощью утилиты Mintsources по «скоростным» показателям, в третьей — сохранился в первозданном виде. Затем определяется группа пакетов, соответствующая имени релиза. В данный момент для нас актуален Trusty, потому как именно из него Mint Rebecca (как и предшествовавшая ей Qiana) черпает все свои основные, не специфичные для него, компоненты. Групп этих три:

просто trusty — в неё входят собственно собственно пакеты дистрибутива;

trusty-updates — «обычные» обновления пакетов, связанные со сменой версий, сборок и исправлением ошибок;

trusty-security — как нетрудно догадаться, обновления, латающие «дыры» в безопасности системы.

На самом деле в репозитории Ubuntu имеются ещё группы trusty-backport и trusty-proposed, но в Mint они по умолчанию не задействованы, а trusty-proposed вообще можно подключить только вручную (чего, впрочем, делать не стоит без очень веских причин). В нашем же файле среди «Ubuntu’йских» строк есть такая:

deb http://archive.canonical.com/ubuntu/ trusty partner

Это репозиторий для пакетов, в том числе и коммерческих, разрабатываемых партнёрами фирмы Canonical. Я, кажется, никогда ничего из него не устанавливал, ни в Mint, ни в Ubuntu, и больше говорить о нём не буду.

Далее в каждой группе идёт перечень категорий пакетов. Их четыре:

• main — полностью свободные пакеты, официально поддерживаемые разработчиками Ubuntu;
• restricted — пакеты, также официально поддерживаемые дистрибутивом, но не вполне свободные;
• universe — полностью свободные программы, официально дистрибутивом не поддерживаемые и развивающиеся силами независимых разработчиков;
• multiverse — пакеты, аналогично universe официально не поддерживаемые и, подобно restricted, не вполне свободные.

«Не вполне свобода» пакетов из категорий restricted и multiverse выражается в ограничениях на их распространение (например, мультимедиа-кодеки, использующие алгоритмы, патентованные в отдельных странах) или могут распространяться только в бинарном виде (фирменные драйверы для видеокарт Nvidia).

До сих пор речь шла о репозиториях бинарных пакетов. Однако существуют и параллельные им репозитории с исходниками. Они подлючаются, если отметить соответствующую опцию в Mintsources — при этом герерируется файл /etc/apt/sources.list.d/official-source-repositories.list. Он устроен точно таким же образом, что и official-package-repositories.list, только в первой позиции каждой его строки будет стоять deb-src:

deb-src http://gd.tuwien.ac.at/opsys/linux/ubuntu/archive trusty main restricted universe multiverse

и так далее.

Особенности репозитория Mint

Репозитории Mint организованы внешне сходно с таковыми Ubuntu, но на самом деле строятся по несколько иным принципам. В файле official-package-repositories.list они описываются двумя строками:

deb http://linux-mint.froonix.org rebecca main upstream import
deb http://extra.linuxmint.com rebecca main

Первая — определяет основной репозиторий для пакетов дистрибутива, распространяемых свободно: это аналог групп main и universe из репозиториев Ubuntu. Как и в последних, в ней указывается URL подключённого по умолчанию или выбранного позднее сервера, а затем имя релиза (на текущий момент — rebecca). Далее следует список категорий, однако тут в это понятие вкладывается несколько иной смысл. Так, категория main включает в себя те самый дистрибутив-специфичные пакеты, о которых я столько говорил раньше: «фирменные» утилиты, MDA, Cinnamon, MATE. В категорию upstream входят пакеты, заимствованные из GNOME 3 и специально пересобранные для совместимости с Mint. Здесь же можно обнаружить пакеты для его Xfce-редакции. Категория же import образована пакетами для KDE-редакции, представленными во всей их полноте.

Кроме трёх перечисленных, в основном репозитории имеются категории backport и romeo. В первой — пакеты, перенесённые из более новых версий в более старые, второй — пакеты в стадии тестирования. Обе эти категории подключаются только в том случае, если в Mintsources были отмечены соответствующие опции (ну или они были прописаны руками в official-package-repositories.list).

Репозиторий extra.linuxmint.com не имеет зеркал (по крайней мере, сейчас) и содержит единственную категорию main, включающую не вполне свободные пакеты — это аналог категорий restricted и multiverse из репозиториев Ubuntu. То есть формально в нём есть и все те же категории, что и в основном репозитории, но они пусты (по крайней мере, в момент сочинения этих строк).

Симметрично строкам для репозиториев бинарных пакетов в файле official-source-repositories.list есть строки для описания репозиториев исходников:

deb-src http://linux-mint.froonix.org rebecca main upstream import
deb-src http://extra.linuxmint.com rebecca main

Файлы списков репозиториев можно (почти) безбоязненно править руками в текстовом редакторе. В частности, именно таким образом осуществляется апгрейд с релиза на релиз (по крайней мере, в пределах одной LTS-версии): для этого достаточно заменить, например, все вхождения qiana на rebecca и выполнить тотальное обновление системы, о чём будет рассказано в своё время.

В заключение же разговора о репозиториях Mint напомню, что их содержимое можно посмотреть визуально в браузере — и основного, и extra.

О PPA-репозиториях

Кроме официального репозитория, для Ubuntu существует централизованное хранилище репозиториев дополнительных, объединяемых понятием PPA — Personal Packages Archive, то есть входящих в персональный архив пакетов, пополняемый сторонними разработчиками и майнтайнерами. А их, вследствие популярности дистрибутива, очень немало. И поэтому свежие версии многих программ, как популярных (что важно для начинающих), так и весьма экзотических (что часто критично для многоопытных), в первую очередь появляются как бинарники в так называемых PPA-репозиториях Ubuntu.

Для доступа к PPA-репозиториям фирмой Canonical разработан специальный онлайновый инструмент — Launchpad, размещённый на одноимённом сайте. Это — не открытая и не свободная система. Более того, она имеет и платную версию, предназначенную для коммерческих пакетов. Однако мы ведь не рататую абстрактной свободы, и нас это не волнует, верно? Цели и задачи Launchpad’а не ограничиваются обеспечением доступа к PPA-репозиториям. Однако остальные его функции предназначены для разработчиков, и потому нас, применителей, также не касаются.

Казалось бы, при чём здесь Mint? А при том, что практически все пакеты из PPA-репозиториев прекрасно устанавливаются в нём и работают точно так же, как в родной Ubuntu. И потому обращение к ним неизбежно, как как крах мировой системы социализма: далеко не всегда потребности применителя в пакетах удовлетворяются офоциальными репозиториями Ubuntu, даже дополненными Mint’овскими.

В разделе про Mintsource мы уже занимались подключением PPA-репозиториев. Теперь посмотрим, что получается в итоге. А вот что: в том же каталоге /etc/apt/sources.list.d/ к спискам официальных репозиториев, official-package-repositories.list и official-source-repositories.list, присоединяются файлы вида *.list — по одному на каждый подключённый репозиторий, где под маской скрывается его так называемое ppa-имя.

Откуда берётся ppa-имя — расскажу в очерке про управление пакетами. А пока — как оно выглядит. Большинство пакетов в PPA-репозиториях собирается и поддерживается майнтайнерами-индивидуалами, и потому здесь нередко можно видеть их имена, фамилии или ники, например, ppa:andrew-crew-kuznetsov/crew — репозиторий, поддерживаемый Андреем Crew Кузнецовым, разработчиком программы XNeur и сборщиком пакета hunspell-ru-ie-yo, словаря для проверки русской орфографии, поддерживающего букву Ё. В других случаях это просто имя пакета, часто с отражением статуса разработки, например, ppa:marlin-devs/marlin-daily — репозиторий «ежедневных» сборок файлового менеджера Marlin. Репозиторий может включать несколько связанных друг с другом пакетов — и тогда называться по главному из них, например: ppa:zfs-native/stable и ppa:zfs-native/daily — репозитории пакетов поддержки ZFS on Linux стабильной и разрабатываемой ветки, соответственно.

Возможны и более причудливые имена, например, ppa:mystic-mirage/komodo-edit — репозиторий текстового редактора Komodo Edit. Важно, что они в обязательном порядке включают «префикс» ppa:, который в имени соответствующего list-файла отбрасывается. Зато завершается последний обязательным компонентом — именем релиза. Например, для Komodo Edit имя list-файла — mystic-mirage-komodo-edit-trusty.list.

Внутри такого файла — обычно две строки. Например, для пакета komodo-edit они будут такими:

deb http://ppa.launchpad.net/mystic-mirage/komodo-edit/ubuntu trusty main
deb-src http://ppa.launchpad.net/mystic-mirage/komodo-edit/ubuntu trusty main

То есть в одном файле описывается и репозиторий бинарников, и репозиторий исходников. Если последний отсутствует — соответствующей строки не будет. Впрочем, в PPA-репозиториях пакетов без исходников не водится. А вот среди «не вполне свободного» софта встречаются, примером чему — браузер Opera: файл opera-stable.list выглядит следующим образом:

deb http://deb.opera.com/opera-stable/ stable non-free #Opera Browser (final releases)

Однако случаи, когда приходится искать пакеты за пределами PPA-репозиториев, очень редки. Ибо в них, как в Греции есть всё — и ещё немного больше, чем всё.

Оглавление