Блок 9

Установка программ: пакетные менеджеры

В Блоке 3 мы уже устанавливали программы через графический App Center, а в уроке 3.3 упоминали, что «под капотом» этого приложения работают те же самые механизмы, которые нам предстоит теперь изучи…

Обновлено: 23 июля 2026 · DeeNet

Введение в блок

В Блоке 3 мы уже устанавливали программы через графический App Center, а в уроке 3.3 упоминали, что «под капотом» этого приложения работают те же самые механизмы, которые нам предстоит теперь изучить полноценно, через терминал. В этом блоке мы разберём, что такое пакет и пакетный менеджер, освоим главный инструмент Ubuntu — APT, а также познакомимся с альтернативными современными системами — Snap, Flatpak и AppImage, и кратко коснёмся сборки программ из исходного кода. Понимание разницы между этими подходами и уверенное владение хотя бы одним из них (APT) — обязательный навык каждого пользователя и администратора Linux.

Урок 9.1. Что такое пакет и пакетный менеджер

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

Теория

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

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

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

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

В мире Linux исторически сложилось несколько разных форматов пакетов и соответствующих им пакетных менеджеров, тесно связанных с конкретными семействами дистрибутивов (вспомните урок 1.4, где мы уже упоминали два основных семейства): формат .deb с менеджером APT, используемый в Debian, Ubuntu и производных от них дистрибутивах (именно этот формат станет центральной темой всего последующего материала этого блока), и формат .rpm с менеджерами DNF/YUM, используемый в Fedora, Rocky Linux, AlmaLinux и других дистрибутивах семейства Red Hat. Помимо этих двух классических, «традиционных» подходов, привязанных к конкретному семейству дистрибутивов, в последние годы появились и универсальные, кроссдистрибутивные форматы — Snap и Flatpak, а также независимый от любых пакетных менеджеров формат AppImage — все три мы подробно рассмотрим в отдельных уроках этого блока.

Практика

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

Шаг 1. Проверьте версию установленной на вашей системе Ubuntu, чтобы понимать контекст дальнейшей практики: `lsb_release -a» (эта команда покажет подробную информацию о версии дистрибутива).

Что вы увидите: несколько строк, включая номер версии Ubuntu (например, «24.04») и кодовое название релиза.

[Скриншот терминала]

Шаг 2. Просмотрите (не изменяя) список настроенных источников пакетов (репозиториев) вашей системы — эту тему подробно разберём в следующем уроке, а пока просто ознакомьтесь: `cat /etc/apt/sources.list» (если этот файл окажется пустым или почти пустым в вашей версии Ubuntu — это нормально, современные версии Ubuntu могут хранить основной список репозиториев в другом, чуть изменённом формате и месте, о чём мы тоже поговорим подробнее в следующем уроке).

Разбор команд

Команда lsb_release

• Назначение:** показывает информацию о версии дистрибутива Linux (LSB — Linux Standard Base, стандарт, к которому исторически относится эта команда).
• Синтаксис:** lsb_release [опции]
• Основные параметры:** `-a» (all, показать всю доступную информацию).
• Реальные примеры использования:** полезно при обращении за технической помощью (на форумах, к коллегам) — точное указание версии дистрибутива часто необходимо для получения корректного совета, так как поведение системы и доступные пакеты могут отличаться между версиями.

Возможные ошибки

• Ошибка:** ожидание, что все дистрибутивы Linux используют один и тот же формат пакетов и одну и ту же команду для их установки.

Почему возникает: новичок, ещё не до конца усвоивший материал урока 1.4 про семейства дистрибутивов, может интуитивно предполагать полную унификацию.

Как определить: попытка использовать команды APT (изучим в следующем уроке) на системе семейства Red Hat (Fedora, Rocky Linux) приведёт к ошибке — там используются принципиально другие команды (DNF/YUM).

Как исправить: определить, к какому семейству относится используемый дистрибутив (вспомните таблицу из урока 1.4), и использовать соответствующий именно этому семейству набор команд.

Как избежать: запомнить чёткую связь: Ubuntu/Debian/Mint — APT; Fedora/Rocky/AlmaLinux — DNF/YUM. Материал этого блока сосредоточен именно на APT, так как весь курс базируется на Ubuntu.

Практические задания

1. Выполните lsb_release -a и запишите в конспект точную версию вашей установленной Ubuntu.
2. Своими словами объясните в конспекте, что такое зависимость пакета, приведя собственный пример (можно гипотетический, не обязательно реальный) программы, зависящей от какой-либо общей библиотеки.

Проверка знаний

Вопрос 1. Что такое зависимость пакета, и почему пакетные менеджеры автоматически её разрешают?

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

Вопрос 2. Какой формат пакетов и какой менеджер используется в Ubuntu, и к какому семейству дистрибутивов это относит Ubuntu?

Ответ: Формат `.deb» с менеджером APT, что относит Ubuntu к семейству Debian (вместе с самим Debian и производными от Ubuntu дистрибутивами вроде Linux Mint).

Итоги урока

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

Вы умеете: определять версию своего дистрибутива через `lsb_release -a».

В следующем уроке потребуется: это понимание, чтобы полноценно освоить главный инструмент управления пакетами в Ubuntu — APT.

Урок 9.2. APT: `apt update`, `apt upgrade`, `apt install`, `apt remove`, репозитории

Освоить APT — центральный, наиболее часто используемый инструмент установки, обновления и удаления программ в Ubuntu, с которым вы, скорее всего, будете взаимодействовать чаще любого другого пакетного менеджера на протяжении всей дальнейшей работы с этим дистрибутивом.

Теория

APT (Advanced Package Tool, «продвинутый инструмент управления пакетами») — это высокоуровневый пакетный менеджер, который мы уже упоминали в уроке 3.3 как систему, стоящую «под капотом» графического App Center. APT сам по себе не занимается непосредственной установкой файлов на диск — эту низкоуровневую работу выполняет более простой инструмент `dpkg», который мы подробно разберём в следующем уроке; APT же берёт на себя более «интеллектуальную» часть работы: поиск пакетов в репозиториях, автоматическое разрешение зависимостей, и удобный, понятный интерфейс командной строки для всех этих операций.

Мы уже мельком заглядывали в предыдущем уроке в файл /etc/apt/sources.list» — именно там (или, в современных версиях Ubuntu, в дополнительной папке /etc/apt/sources.list.d/», содержащей отдельные файлы для дополнительных репозиториев) хранится список репозиториев — адресов серверов в интернете, откуда APT скачивает пакеты. Важно понимать: APT не «знает» в реальном времени о содержимом всех этих репозиториев автоматически — вместо этого он периодически (или по явной команде пользователя) скачивает и сохраняет локальный кэш — своего рода «слепок», список всех доступных пакетов и их версий на момент последнего обновления этого кэша. Именно с этим связана важнейшая практическая команда, с которой должна начинаться практически любая работа с APT:

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

apt upgrade — обновляет уже установленные в системе пакеты до последних доступных версий, согласно только что обновлённому (командой apt update) локальному кэшу. Именно поэтому эти две команды почти всегда используются в связке одна за другой: сначала update» (узнать, что нового доступно), затем upgrade» (собственно обновить).

apt install — устанавливает указанный новый пакет (программу), автоматически разрешая и устанавливая все необходимые зависимости.

apt remove — удаляет указанный пакет, но, аналогично уже знакомой нам ситуации с userdel» без параметра -r» из Блока 8, по умолчанию оставляет нетронутыми некоторые связанные с программой файлы конфигурации, предполагая возможность последующей переустановки той же программы с сохранением прежних персональных настроек. Для полного удаления, включая файлы конфигурации, используется команда apt purge (буквально «вычистить, очистить полностью»).

Практически важный момент: команды apt update, apt upgrade, apt install, apt remove, apt purge» — все они изменяют состояние системы в целом (устанавливают/удаляют программы, доступные всем пользователям компьютера), поэтому, в полном соответствии с материалом Блока 8, все они требуют выполнения через sudo».

Практика

Шаг 1. Обновите локальный кэш списка пакетов: `sudo apt update».

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

[Скриншот терминала]

Шаг 2. Обновите уже установленные пакеты до последних доступных версий: `sudo apt upgrade».

Что произойдёт: APT покажет список пакетов, которые будут обновлены, суммарный размер загрузки, и запросит подтверждение (обычно достаточно нажать Y» и Enter, либо просто Enter, если Y» является вариантом по умолчанию, что часто отображается заглавной буквой в квадратных скобках подсказки).

[Скриншот настроек]

Шаг 3. Установите новую программу — воспользуемся простым и полезным примером, командой tree» (утилита для наглядного отображения структуры папок в виде дерева, которая может пригодиться вам для дальнейшей практики курса, хотя мы обходились без неё, используя ls -R» из Блока 5): `sudo apt install tree».

Что произойдёт: APT покажет, что будет установлен указанный пакет (возможно, вместе с какими-либо зависимостями, если они потребуются), запросит подтверждение, и после его получения скачает и установит программу.

Шаг 4. Проверьте, что программа действительно установлена и работает: перейдите в свою учебную папку курса и выполните `tree ~/Linux-Course» (или любую другую папку с вложенной структурой из ваших предыдущих практических заданий).

Что вы увидите: наглядное, визуальное древовидное представление структуры папок и файлов — куда более удобное для быстрого обзора сложной структуры, чем построчный вывод `ls -R».

[Скриншот результата]

Шаг 5. Удалите программу, оставив файлы конфигурации (хотя у такой простой утилиты, как tree, специфических пользовательских конфигурационных файлов может и не быть — само действие всё равно полезно для практики синтаксиса команды): `sudo apt remove tree».

Шаг 6. Установите программу заново для завершающей демонстрации полного удаления: sudo apt install tree» ещё раз, а затем удалите её полностью, включая любые возможные конфигурационные файлы: sudo apt purge tree».

Разбор команд

Команда apt update

• Назначение:** обновляет локальный кэш информации о доступных в репозиториях пакетах и их версиях.
• Синтаксис:** `sudo apt update»
• Типичные ошибки:** ожидание, что эта команда сама по себе обновит установленные программы.

Способы исправления: после apt update» всегда выполнять отдельную команду apt upgrade», если требуется именно обновление уже установленных программ.

Команда apt upgrade

• Назначение:** обновляет уже установленные пакеты до последних доступных версий согласно текущему локальному кэшу.
• Синтаксис:** sudo apt upgrade [опции]
• Основные параметры:** -y (yes, автоматически подтвердить все запросы, без ожидания ручного ввода — полезно для автоматизации в скриптах, тема Блока 15, но требует осторожности при интерактивном использовании, так как отключает возможность заметить и отменить нежелательное действие до его выполнения).
• Дополнительные параметры:** существует также команда apt full-upgrade» (или более старое историческое название dist-upgrade), которая, в отличие от обычного upgrade`, при необходимости может устанавливать новые пакеты или удалять старые, если этого требует корректное разрешение более сложных зависимостей при обновлении — используется реже, для более существенных, комплексных обновлений.

Команда apt install

• Назначение:** устанавливает указанный пакет вместе с необходимыми зависимостями.
• Синтаксис:** sudo apt install [опции] имя_пакета [имя_пакета2 ...]
• Реальные примеры использования:** sudo apt install git curl wget» — установить сразу несколько полезных программ одной командой, перечислив их имена через пробел (мы вернёмся к git подробно в Блоке 16, а curl/wget» — полезные утилиты для скачивания файлов из интернета через терминал, с которыми мы ещё можем столкнуться в последующих блоках).
• Типичные ошибки:** попытка установить пакет с неверно набранным именем.

Как определить: сообщение вида `Unable to locate package» («Не удаётся найти пакет»).

Способы исправления: проверить точное написание имени пакета (можно воспользоваться поиском, который разберём в следующем уроке через apt search), убедиться, что был предварительно выполнен `apt update», так как пакет мог быть недавно добавлен в репозиторий уже после последнего обновления локального кэша.

Команда apt remove и apt purge

• Назначение:** remove» удаляет пакет, оставляя файлы конфигурации; purge» удаляет пакет полностью, включая конфигурационные файлы.
• Синтаксис:** sudo apt remove имя_пакета» / sudo apt purge имя_пакета»
• Типичные ошибки:** использование `remove» там, где предполагалась полная, окончательная очистка от программы, включая все её персональные настройки, что впоследствии может привести к путанице, если через какое-то время та же программа переустанавливается «с чистого листа», но неожиданно сохраняет старые настройки.

Способы исправления: использовать purge» вместо remove`, когда действительно требуется полная очистка.

Возможные ошибки

• Ошибка:** длительное отсутствие выполнения apt update, из-за чего локальный кэш сильно устаревает, и попытки установить относительно новые пакеты завершаются ошибками, хотя на самом деле пакет уже доступен в репозитории, просто локальная информация об этом устарела.

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

Как определить: сообщение `Unable to locate package» для пакета, который точно должен существовать (можно проверить, поискав его название в интернете на официальном сайте пакетов Ubuntu).

Как исправить: выполнить `sudo apt update» и повторить попытку установки.

Как избежать: сформировать привычку — практически всегда выполнять apt update» непосредственно перед apt install» или `apt upgrade», особенно если с момента последнего обновления кэша прошло значительное время.

Практические задания

1. Выполните полный цикл sudo apt update» и sudo apt upgrade» на своей системе и запишите в конспект, сколько пакетов было обновлено (или зафиксируйте, что система уже была полностью актуальна).
2. Установите любую полезную для себя программу через apt install» (можно любую другую, помимо tree», по вашему выбору) и проверьте её работоспособность.
3. Продемонстрируйте на практике разницу между apt remove» и apt purge»: установите тестовую программу, создайте (если возможно) или найдите связанный с ней конфигурационный файл, удалите программу через remove» и проверьте, остался ли файл конфигурации, а затем удалите её же (переустановив предварительно, если требуется) уже через purge» и снова проверьте результат.

Проверка знаний

Вопрос 1. Почему команду apt update почти всегда рекомендуется выполнять перед apt install или apt upgrade?

Ответ: Потому что apt update синхронизирует локальный кэш информации о доступных пакетах с актуальным состоянием репозиториев. Без этого шага APT может «не знать» о недавно добавленных пакетах или новых версиях уже установленных программ, работая с устаревшей, закешированной информацией.

Вопрос 2. В чём разница между apt remove и apt purge?

Ответ: apt remove удаляет саму программу, но оставляет её файлы конфигурации на диске (на случай последующей переустановки с сохранением персональных настроек). `apt purge» удаляет программу полностью, включая все связанные с ней конфигурационные файлы.

Итоги урока

Вы изучили: назначение APT, понятие репозиториев и локального кэша, команды apt update, apt upgrade, apt install, apt remove, `apt purge».

Вы умеете: обновлять систему, устанавливать и полностью удалять программы через APT.

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

Урок 9.3. Низкоуровневый `dpkg`, установка `.deb` файлов

Понять, как APT работает «под капотом» через более базовый инструмент dpkg, и научиться устанавливать программы из отдельных .deb-файлов, скачанных напрямую с сайтов разработчиков — ситуация, с которой вы неизбежно столкнётесь для некоторых программ, не распространяемых через стандартные репозитории Ubuntu.

Теория

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

Практическая ситуация, где dpkg» становится действительно необходим напрямую: некоторые программы (особенно коммерческие или не входящие в официальные репозитории Ubuntu по различным причинам) распространяются разработчиками в виде отдельного .deb-файла для скачивания прямо с их официального сайта. В этом случае стандартный apt install» не подходит (так как эта команда ищет пакет именно в настроенных репозиториях, а не по произвольному локальному пути к файлу), и потребуется именно `dpkg».

Практика

Для практики этого урока нам понадобится реальный .deb-файл. Используем безопасный, официальный пример — программу для просмотра видео VLC, доступную для скачивания напрямую с официального сайта, хотя в действительности она также присутствует и в стандартных репозиториях Ubuntu (мы намеренно выбираем такой пример именно ради безопасной, контролируемой практики, хотя на практике для VLC было бы разумнее и проще использовать именно apt install vlc).

Шаг 1. Скачайте .deb-файл (в реальности для такой практики вы можете использовать любой другой безопасный .deb-файл, который найдёте на официальном сайте знакомой вам программы — принцип будет идентичен) — например, через браузер внутри вашей виртуальной машины перейдите на официальный сайт нужной вам программы и скачайте .deb-файл в папку `~/Downloads» (аналогично тому, как мы скачивали ISO-образ Ubuntu в Блоке 2).

Шаг 2. Перейдите в папку с загрузками и просмотрите информацию о скачанном пакете, не устанавливая его, с помощью параметра -I» (info): cd ~/Downloads» и `dpkg -I имя_файла.deb» (подставив реальное имя скачанного файла).

Что вы увидите: подробную информацию о пакете — его точное имя, версию, архитектуру (например, amd64), описание, и, что особенно важно, список зависимостей — других пакетов, необходимых для его корректной работы.

[Скриншот терминала]

Шаг 3. Установите пакет с помощью dpkg» напрямую: sudo dpkg -i имя_файла.deb» (параметр `-i» означает install).

Что может произойти: если у пакета есть зависимости, которые ещё не установлены в системе, dpkg» сообщит об ошибке незавершённой установки из-за отсутствующих зависимостей (вспомните теорию — dpkg» сам по себе не умеет автоматически их разрешать, в отличие от APT).

Шаг 4. Если возникла ситуация из шага 3 — исправим её элегантным, широко распространённым в сообществе способом, комбинируя dpkg» с уже знакомым APT: sudo apt install -f» (параметр -f», fix, «исправить» — эта команда просканирует систему на предмет незавершённых, «сломанных» из-за отсутствующих зависимостей установок, и попробует автоматически найти и установить именно недостающие зависимости через APT, довершив тем самым установку, начатую через dpkg`).

Шаг 5. Проверьте, что пакет успешно установлен, запросив информацию об уже установленном (а не только скачанном) пакете через dpkg -l» (list) в сочетании с уже знакомым нам grep» из Блока 6: `dpkg -l | grep имя_программы».

Разбор команд

Команда dpkg

• Назначение:** низкоуровневая установка, удаление и запрос информации об отдельных .deb-пакетах.
• Синтаксис:** sudo dpkg [опции] аргумент
• Основные параметры:** -i файл.deb» (install, установить конкретный локальный файл пакета); -r имя_пакета» (remove, удалить установленный пакет, аналогично apt remove, но без автоматической работы с зависимостями); -l» (list, показать список всех установленных в системе пакетов); -I файл.deb» (info, показать информацию о пакете без установки); `-L имя_пакета» (list files, показать список всех файлов, установленных данным конкретным пакетом на диск).
• Реальные примеры использования:** dpkg -L tree» (продолжая пример из предыдущего урока) — узнать, какие именно файлы на диске были установлены пакетом tree», что может быть полезно для понимания структуры установленной программы.
• Типичные ошибки:** попытка установить .deb-файл, предназначенный для другой архитектуры процессора (например, arm64» вместо ожидаемой на большинстве обычных компьютеров amd64`).

Как определить: сообщение об ошибке несовпадения архитектуры.

Способы исправления: убедиться, что скачан правильный .deb-файл, соответствующий архитектуре вашего компьютера (для большинства современных обычных компьютеров и виртуальных машин это amd64).

Возможные ошибки

• Ошибка:** установка .deb-файлов из непроверенных, ненадёжных источников в интернете.

Почему возникает: недостаточная осторожность при поиске нужной программы, доверие к неофициальным сайтам.

Как определить: сложно определить без специального анализа — это скорее вопрос профилактики, чем распознавания уже свершившегося факта.

Как исправить: если программа была установлена из сомнительного источника и есть подозрения на вредоносность — удалить её (dpkg -r» или apt remove`) и, при серьёзных опасениях, рассмотреть более глубокую проверку системы на предмет компрометации (тема, тесно связанная с Блоком 14, посвящённым безопасности).

Как избежать: всегда скачивать .deb-файлы только с официальных сайтов разработчиков программ (аналогично уже неоднократно повторявшемуся в курсе правилу для ISO-образов и других загружаемых файлов), избегая сторонних агрегаторов и файлообменников с сомнительной репутацией.

Практические задания

1. Выполните `dpkg -l | wc -l» (используя уже знакомую нам команду подсчёта строк из Блока 6), чтобы узнать, сколько всего пакетов установлено в вашей системе на данный момент — вероятно, это удивительно большое число, учитывая множество системных библиотек и служебных компонентов.
2. Выберите любой уже установленный в вашей системе пакет (например, tree» из предыдущего урока, если вы его ещё не удалили, или любой другой) и просмотрите список всех установленных им файлов через dpkg -L».
3. Если у вас есть возможность безопасно скачать .deb-файл с официального сайта какой-либо программы — повторите практику этого урока самостоятельно, включая обработку возможной ситуации с недостающими зависимостями через `apt install -f».

Проверка знаний

Вопрос 1. Почему `dpkg -i» иногда завершается ошибкой из-за отсутствующих зависимостей, хотя APT обычно устанавливает программы без подобных проблем?

Ответ: Потому что dpkg» — низкоуровневый инструмент, который не умеет самостоятельно обращаться к репозиториям и автоматически разрешать зависимости, в отличие от APT. Он работает только с уже готовым локальным файлом, и если для него требуются дополнительные, ещё не установленные пакеты, dpkg» просто сообщает об этой проблеме, не решая её самостоятельно.

Вопрос 2. Как можно исправить ситуацию с незавершённой установкой пакета через `dpkg -i» из-за отсутствующих зависимостей?

Ответ: Выполнить команду `sudo apt install -f», которая просканирует систему на предмет незавершённых установок и автоматически найдёт и установит недостающие зависимости через APT, довершив установку.

Итоги урока

Вы изучили: назначение dpkg» как низкоуровневого инструмента, работающего «под капотом» у APT, и способ установки отдельных .deb`-файлов, скачанных напрямую с сайтов разработчиков.

Вы умеете: устанавливать, просматривать информацию, и корректно обрабатывать проблемы с зависимостями при работе с отдельными .deb-пакетами.

В следующем уроке потребуется: понимание классического формата .deb, чтобы сравнить его с современными, кроссдистрибутивными альтернативами — начнём со Snap.

Урок 9.4. Snap: изолированные пакеты

Понять принципиально иной, более современный подход к упаковке и распространению программ, предложенный компанией Canonical (разработчиком Ubuntu) — формат Snap, с которым вы уже неявно сталкивались в Блоке 3 через App Center.

Теория

Классический подход .deb/APT, который мы изучили в предыдущих двух уроках, имеет одно существенное практическое ограничение: пакет `.deb» обычно опирается на определённые версии системных библиотек, уже установленных в самой операционной системе (те самые зависимости, о которых мы говорили в уроке 9.1) — что создаёт определённую взаимозависимость между версией конкретного дистрибутива и тем, какие именно версии программ можно на него корректно установить, а также иногда приводит к конфликтам, если разным программам требуются разные, несовместимые между собой версии одной и той же общей библиотеки.

Snap — формат пакетов, разработанный компанией Canonical, решающий эту проблему принципиально иным подходом: каждый snap-пакет включает в себя все необходимые ему зависимости прямо внутри себя же, полностью изолированно от остальной системы (отсюда и определение «изолированные пакеты» в названии этого урока). Такой подход называется в общей IT-терминологии контейнеризацией приложения (более глубоко и подробно к концепции контейнеров, уже в контексте Docker, мы вернёмся в Блоке 17 — Snap использует концептуально похожую, хотя технически несколько отличающуюся идею изоляции).

Практические следствия такого подхода:

• одна и та же snap-программа гарантированно работает одинаково на разных дистрибутивах Linux (не только на Ubuntu, но и на многих других, поддерживающих технологию Snap), так как ей не требуется полагаться на конкретные версии системных библиотек хост-системы;
• snap-пакеты автоматически обновляются в фоновом режиме без явного участия пользователя (в отличие от APT, где обновление обычно требует явного выполнения apt upgrade);
• обратная сторона той же изолированности — snap-пакеты обычно занимают больше места на диске (так как каждый пакет несёт с собой собственную копию необходимых зависимостей, вместо использования общих системных библиотек совместно с другими программами) и иногда запускаются несколько медленнее при первом старте по сравнению с классическими .deb-пакетами.

Snap-пакеты скачиваются не из классических APT-репозиториев, а из отдельного каталога — Snap Store (магазин Snap-приложений), и управляются отдельной командой snap, а не `apt».

Практика

Шаг 1. Проверьте, что система Snap установлена и работает (в Ubuntu она предустановлена по умолчанию): `snap version».

Что вы увидите: версии как самой команды snap, так и связанной с ней фоновой службы `snapd», обеспечивающей работу всей системы Snap.

[Скриншот терминала]

Шаг 2. Просмотрите список уже установленных в системе snap-пакетов: `snap list».

Что вы увидите: список, вероятно, включающий несколько предустановленных Ubuntu системных компонентов, использующих именно формат Snap (например, core», обеспечивающий работу самой системы Snap, или snap-store» — графическая версия магазина приложений).

Шаг 3. Найдите новый snap-пакет для установки, используя поиск: `snap find "text editor"» (найдём текстовый редактор в качестве примера).

Что вы увидите: список найденных snap-пакетов, соответствующих запросу, с кратким описанием каждого.

[Скриншот результата]

Шаг 4. Установите один из найденных пакетов (выберите любой безопасный, вызвавший ваш интерес пакет из результатов поиска, либо используйте конкретный пример, если знаете его точное название) — например, установим редактор кода: `sudo snap install nano» (проверим, доступна ли уже знакомая нам по Блоку 7 программа nano и в виде snap-пакета, хотя в базовой Ubuntu она уже предустановлена через APT — эта команда в первую очередь демонстрирует сам синтаксис).

Шаг 5. Проверьте список установленных snap-пакетов ещё раз: `snap list».

Шаг 6. Удалите тестовый snap-пакет, если он не нужен для дальнейшей работы: sudo snap remove nano» (обратите внимание: если у вас уже есть предустановленный через APT nano`, эта команда удалит именно отдельную snap-версию, если она была установлена, не затрагивая изначальную версию из APT — обе системы работают параллельно, независимо друг от друга).

Разбор команд

Команда snap

• Назначение:** управление snap-пакетами — установка, удаление, поиск, просмотр списка.
• Синтаксис:** snap [подкоманда] [опции] [аргумент]
• Основные параметры:** install имя» (установить пакет, обычно требует sudo, аналогично APT); remove имя» (удалить пакет); find запрос» (найти пакеты по ключевому слову); list» (показать установленные пакеты); `refresh» (обновить все snap-пакеты вручную, хотя, как упоминалось в теории, обычно это происходит автоматически в фоне).
• Реальные примеры использования:** sudo snap install code --classic» — характерный реальный пример установки популярной среды разработки Visual Studio Code через Snap (параметр --classic» здесь означает менее строгую изоляцию, необходимую некоторым программам для полноценного доступа к файловой системе — некоторые сложные приложения требуют такого «классического» режима вместо полной изоляции по умолчанию).

Возможные ошибки

• Ошибка:** установка одной и той же программы одновременно и через APT, и через Snap, не осознавая этого, что приводит к путанице, какая именно версия запускается по умолчанию, и избыточному занятому месту на диске.

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

Как определить: неожиданное поведение программы (например, отсутствие ожидаемых личных настроек, характерное при переключении между изолированной snap-версией и обычной версией из APT с разными путями хранения данных) или простое замечание о необычно большом использовании дискового пространства.

Способы исправления: определить, какая версия программы (snap или .deb) на самом деле нужна и используется, и удалить дублирующуюся, ненужную версию.

Как избежать: перед установкой новой программы кратко проверять (например, через snap list» и dpkg -l | grep», как мы уже практиковали ранее), не установлена ли она уже в другом формате.

Практические задания

1. Выполните `snap list» и опишите в конспекте, какие именно snap-пакеты уже присутствуют в вашей системе по умолчанию, предположив назначение каждого по названию.
2. Найдите через `snap find» любую интересующую вас программу и запишите в конспект три найденных варианта с их краткими описаниями, не обязательно устанавливая их.
3. Своими словами (без подглядывания) объясните в конспекте главное практическое отличие подхода Snap от классического подхода .deb/APT, опираясь на понятие изолированности пакетов.

Проверка знаний

Вопрос 1. В чём заключается принципиальное отличие подхода Snap от классического .deb-пакета в контексте зависимостей?

Ответ: Snap-пакет включает все необходимые ему зависимости внутри себя же, полностью изолированно от остальной системы, тогда как классический .deb-пакет обычно опирается на определённые версии системных библиотек, уже установленных в самой операционной системе.

Вопрос 2. Какие два практических недостатка есть у изолированного подхода Snap по сравнению с классическими .deb-пакетами?

Ответ: Snap-пакеты обычно занимают больше места на диске (так как несут собственную копию зависимостей вместо использования общих системных библиотек) и иногда запускаются несколько медленнее при первом старте.

Итоги урока

Вы изучили: концепцию изолированных пакетов Snap, их практические преимущества (кроссдистрибутивность, автоматические обновления) и недостатки (размер, скорость запуска) по сравнению с классическим .deb.

Вы умеете: искать, устанавливать, просматривать список и удалять snap-пакеты через команду `snap».

В следующем уроке потребуется: это понимание изолированных пакетов, чтобы сравнить Snap с ещё одной похожей, но независимой от Canonical альтернативой — Flatpak.

Урок 9.5. Flatpak: альтернативная система пакетов

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

Теория

Flatpak — формат пакетов, концептуально очень похожий на уже изученный в предыдущем уроке Snap: он тоже реализует принцип изолированности, включая необходимые зависимости внутри самого пакета, и тоже стремится обеспечить кроссдистрибутивную совместимость, работая одинаково на разных дистрибутивах Linux. Ключевое отличие от Snap — Flatpak разрабатывается независимым, открытым сообществом разработчиков (проект тесно связан с сообществом рабочего стола GNOME, о котором мы говорили в уроке 3.1), а не одной коммерческой компанией, как Canonical в случае со Snap. Это различие иногда становится предметом определённых дискуссий и предпочтений в сообществе Linux (некоторые пользователи и разработчики предпочитают более открытую, не привязанную к одной компании модель разработки Flatpak), но с чисто практической точки зрения, для рядового пользователя, оба формата решают очень похожую задачу похожим образом.

В отличие от Snap, который в Ubuntu предустановлен и готов к использованию «из коробки» (так как это разработка самой Canonical), Flatpak в стандартной установке Ubuntu не предустановлен по умолчанию и требует отдельной, дополнительной установки перед первым использованием — что даёт хорошую возможность применить на практике уже изученные в этом же блоке команды APT (для установки самого инструмента Flatpak) в сочетании с новым инструментом Flatpak (для установки конкретных программ через него).

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

Практика

Шаг 1. Установите сам инструмент Flatpak через уже хорошо знакомый нам APT (обратите внимание на комбинирование материала двух уроков этого блока): sudo apt update» (хорошая практика перед любой новой установкой, вспомните урок 9.2), затем sudo apt install flatpak».

Что произойдёт: APT скачает и установит саму систему Flatpak — пока ещё без каких-либо конкретных программ, только базовую инфраструктуру, необходимую для дальнейшей работы с этим форматом.

[Скриншот терминала]

Шаг 2. Добавьте публичный репозиторий Flathub в качестве источника пакетов Flatpak: `flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo».

Что делает эта команда: параметр --if-not-exists» защищает от ошибки, если этот источник уже был добавлен ранее (полезная практика при написании команд, которые могут выполняться повторно, — вспомните похожую по духу идею параметра -p» у `mkdir» из Блока 5, тоже предотвращающего ошибку при уже существующем состоянии).

Шаг 3. Перезагрузите виртуальную машину (вспомните процесс перезагрузки из предыдущих блоков), так как после первой установки Flatpak иногда требуется перезапуск сессии для корректной интеграции с системой (это специфическая практическая особенность именно Flatpak, связанная с некоторыми системными переменными окружения, которые должны быть корректно инициализированы при новом входе в систему).

Шаг 4. После перезагрузки откройте терминал заново и найдите какую-либо программу через Flatpak: `flatpak search "image viewer"» (найдём программу для просмотра изображений в качестве примера).

Что вы увидите: список найденных Flatpak-пакетов, соответствующих запросу, с их названиями, краткими описаниями и полными идентификаторами (обычно в формате, напоминающем доменное имя в обратном порядке, например org.gnome.eog).

[Скриншот результата]

Шаг 5. Установите одну из найденных программ, используя её точный идентификатор из результатов поиска: flatpak install flathub org.gnome.eog» (или любой другой идентификатор, найденный на предыдущем шаге, соответствующий заинтересовавшей вас программе — обратите внимание, здесь конкретно указано слово flathub», обозначающее источник, из которого следует установить пакет, что логично при наличии потенциально нескольких настроенных источников одновременно).

Шаг 6. Проверьте список установленных через Flatpak приложений: `flatpak list».

Шаг 7. Удалите тестовое приложение, если оно больше не нужно: `flatpak uninstall org.gnome.eog» (подставив реальный идентификатор установленной вами программы).

Разбор команд

Команда flatpak

• Назначение:** управление Flatpak-пакетами — установка, удаление, поиск, просмотр списка, управление источниками.
• Синтаксис:** flatpak [подкоманда] [опции] [аргумент]
• Основные параметры:** remote-add» (добавить новый источник пакетов); search запрос» (поиск); install источник идентификатор» (установка); uninstall идентификатор» (удаление); list» (список установленного); update» (обновление всех Flatpak-приложений).
• Реальные примеры использования:** `flatpak install flathub com.spotify.Client» — характерный пример установки популярного музыкального сервиса через Flatpak, если он недоступен или неудобен для установки через стандартные репозитории APT.

Возможные ошибки

• Ошибка:** попытка установить Flatpak-приложение без предварительного добавления источника Flathub (или иного нужного источника).

Почему возникает: новичок пропускает шаг 2 практики этого урока, считая, что достаточно самого установленного инструмента `flatpak» без явно настроенного источника пакетов.

Как определить: команда flatpak search» или flatpak install» не находит ожидаемые пакеты, либо явно сообщает об отсутствии настроенных удалённых источников.

Способы исправления: выполнить команду добавления источника из шага 2 практики этого урока.

Как избежать: запомнить, что, в отличие от Snap (где Snap Store настроен автоматически при предустановке в Ubuntu), Flatpak требует явного, отдельного шага добавления источника пакетов (чаще всего именно Flathub) сразу после установки самого инструмента.

Практические задания

1. Установите Flatpak и добавьте источник Flathub, следуя шагам практики этого урока.
2. Найдите через `flatpak search» три любых интересующих вас программы и запишите в конспект их точные идентификаторы вместе с краткими описаниями.
3. Своими словами объясните в конспекте, чем Flatpak концептуально похож на изученный в предыдущем уроке Snap, и в чём заключается их ключевое организационное (не техническое) отличие.

Проверка знаний

Вопрос 1. Предустановлен ли Flatpak в стандартной установке Ubuntu, в отличие от Snap?

Ответ: Нет, в отличие от Snap (который является разработкой самой Canonical и предустановлен в Ubuntu по умолчанию), Flatpak требует отдельной, дополнительной установки через APT перед первым использованием.

Вопрос 2. Как называется наиболее известный и широко используемый публичный каталог Flatpak-пакетов, аналогичный Snap Store для формата Snap?

Ответ: Flathub.

Итоги урока

Вы изучили: концепцию Flatpak как альтернативного изолированного формата пакетов, его организационное отличие от Snap, и необходимость дополнительной установки и настройки источника Flathub.

Вы умеете: устанавливать и настраивать Flatpak, искать, устанавливать, просматривать список и удалять Flatpak-пакеты.

В следующем уроке потребуется: понимание обоих изолированных форматов (Snap и Flatpak), чтобы познакомиться с третьим, ещё более простым и независимым подходом — AppImage.

Урок 9.6. AppImage: портативные приложения

Освоить AppImage — третий, принципиально иной подход к распространению программ в Linux, не требующий вообще никакого пакетного менеджера или установки в привычном смысле этого слова.

Теория

AppImage — это формат распространения программ, кардинально отличающийся от всех трёх ранее изученных подходов (APT/dpkg, Snap, Flatpak) одной ключевой особенностью: AppImage-файл представляет собой единый, самодостаточный исполняемый файл, содержащий внутри себя абсолютно всё необходимое для работы программы (саму программу и все нужные ей зависимости, аналогично уже знакомой нам по Snap/Flatpak идее изолированности), но при этом не требующий никакой установки вообще — ни через какой-либо пакетный менеджер, ни через dpkg, ни через snap/flatpak». Файл просто скачивается, помечается как исполняемый (вспомните право на выполнение x» из Блока 8), и запускается напрямую — отсюда и характеристика «портативное приложение» в названии этого урока: программа буквально «переносится» как единый файл, без необходимости какого-либо процесса установки в систему в привычном понимании.

Практические следствия такого подхода:

• максимальная простота использования для конечного пользователя — не требуется даже понимания, что такое пакетный менеджер;
• отсутствие какой-либо централизованной системы обновлений — в отличие от APT, Snap и Flatpak, где обновления программ происходят через соответствующий пакетный менеджер, AppImage-приложения обычно нужно обновлять вручную, скачивая новую версию файла и заменяя старую (хотя некоторые AppImage-приложения включают собственный встроенный механизм проверки обновлений — это зависит от конкретного разработчика конкретной программы, а не является универсальным свойством самого формата);
• программа не интегрируется автоматически в системное меню приложений (то самое меню, которое мы находили через «Activities» в Блоке 3) без дополнительных, отдельных шагов настройки — с точки зрения системы AppImage-файл — это просто обычный исполняемый файл, лежащий там, куда вы его скачали, а не «установленная» в привычном смысле программа.

Практика

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

Шаг 1. Скачайте любой AppImage-файл с официального сайта интересующей вас программы (многие современные open-source приложения предлагают AppImage как один из вариантов скачивания) в папку `~/Downloads».

Шаг 2. Проверьте текущие права доступа к скачанному файлу (вспомните материал Блока 8): `ls -l ~/Downloads/имя_файла.AppImage».

Что вы увидите: скорее всего, право на выполнение (x) изначально отсутствует — большинство браузеров по умолчанию не устанавливают этот флаг автоматически при скачивании файлов, из соображений безопасности (чтобы случайно скачанный исполняемый файл не мог быть запущен одним лишь двойным щелчком без осознанного, явного разрешения пользователя).

[Скриншот терминала]

Шаг 3. Добавьте право на выполнение, используя уже хорошо знакомую нам команду chmod» из Блока 8: chmod +x ~/Downloads/имя_файла.AppImage».

Шаг 4. Проверьте результат: ls -l ~/Downloads/имя_файла.AppImage» — теперь должен присутствовать символ x» в правах доступа.

Шаг 5. Запустите приложение напрямую, используя уже знакомый нам синтаксис явного указания пути к исполняемому файлу из текущей папки (вспомните обозначение . из Блока 5, означающее текущую папку): cd ~/Downloads» и ./имя_файла.AppImage» (обратите внимание на обязательное ./ перед именем файла — без этого явного указания на текущую папку Bash попытался бы искать программу с таким именем в папках из переменной $PATH, изученной в Блоке 6, а не в текущей рабочей директории, что привело бы к ошибке «command not found»).

Что произойдёт: приложение должно запуститься напрямую, без какого-либо процесса установки — просто как обычная запущенная программа.

[Скриншот результата]

Разбор команд

В этом уроке мы не вводим новых команд — применяем уже хорошо знакомые нам chmod +x» (Блок 8) для придания файлу свойства исполняемого, и синтаксис ./имя_файла» для запуска исполняемого файла из текущей папки, который мы уже упоминали, но не разбирали подробно, в контексте путей в Блоке 5.

Синтаксис ./

• Назначение:** явно указывает, что нужно запустить исполняемый файл, находящийся именно в текущей рабочей папке, а не искать программу с таким именем среди папок, перечисленных в переменной `$PATH».
• Реальные примеры использования:** `./script.sh» — запуск собственного, ещё не «официально» установленного в систему скрипта (тема которого подробно раскроется уже в Блоке 15) прямо из папки, где он находится.

Возможные ошибки

• Ошибка:** попытка запустить AppImage-файл сразу после скачивания, без предварительного добавления права на выполнение через `chmod +x».

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

Как определить: сообщение об ошибке Permission denied» (уже знакомое нам из множества предыдущих ситуаций в Блоке 8) при попытке выполнить ./имя_файла.AppImage».

Способы исправления: выполнить `chmod +x» перед повторной попыткой запуска.

Как избежать: запомнить это как стандартный, обязательный первый шаг при работе с любым скачанным AppImage-файлом (или, в более широком смысле, с любым скачанным исполняемым файлом, ещё не имеющим прав на выполнение).

Практические задания

1. Если у вас получилось безопасно скачать реальный AppImage-файл в рамках практики этого урока — повторите весь цикл (проверка прав, добавление права на выполнение, запуск) самостоятельно, без подглядывания в инструкцию.
2. Своими словами объясните в конспекте, почему AppImage-приложения обычно не интегрируются автоматически в системное меню приложений, в отличие от программ, установленных через APT, Snap или Flatpak — опираясь на теорию этого урока о том, что AppImage технически не является «установленной» в привычном смысле программой.
3. Составьте в конспекте краткую сравнительную таблицу всех четырёх изученных в этом блоке подходов (APT/.deb, Snap, Flatpak, AppImage) по критериям: требуется ли установка, как происходят обновления, интегрируется ли в системное меню автоматически.

Проверка знаний

Вопрос 1. Что нужно обязательно сделать со скачанным AppImage-файлом перед его первым запуском?

Ответ: Добавить право на выполнение с помощью команды `chmod +x», так как большинство браузеров не устанавливают это право автоматически при скачивании файлов из соображений безопасности.

Вопрос 2. Как происходят обновления AppImage-приложений, в отличие от программ, установленных через APT, Snap или Flatpak?

Ответ: У AppImage нет какой-либо централизованной системы обновлений через пакетный менеджер — пользователю обычно нужно вручную скачать новую версию файла и заменить им старую (если только сама конкретная программа не включает собственный встроенный механизм проверки обновлений, что не является универсальным свойством формата в целом).

Итоги урока

Вы изучили: концепцию AppImage как портативного, самодостаточного формата, не требующего установки, его практические плюсы (простота) и минусы (отсутствие централизованных обновлений и автоматической интеграции в систему).

Вы умеете: подготавливать и запускать AppImage-файлы, придавая им право на выполнение.

В следующем уроке потребуется: полное понимание всех четырёх подходов к получению готовых программ, чтобы кратко познакомиться с последним, самым фундаментальным вариантом — установкой программы напрямую из её исходного кода.

Урок 9.7. Сборка из исходного кода: `configure`, `make`, `make install` (обзорно)

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

Теория

Все четыре способа получения программ, изученные в предыдущих уроках этого блока (APT/.deb, Snap, Flatpak, AppImage), объединяет одна общая черта: во всех случаях вы получаете уже готовую, скомпилированную программу, полностью подготовленную для непосредственного запуска. Но откуда изначально берутся эти скомпилированные версии?

Вспомните урок 1.3: свободное программное обеспечение подразумевает открытый исходный код (source code) — текст программы, написанный разработчиком на определённом языке программирования (например, на языке C, на котором написана значительная часть самого ядра Linux и множества системных утилит). Этот исходный текст непонятен и неисполним для процессора компьютера напрямую — его необходимо скомпилировать (compile), то есть преобразовать в машинный код, который процессор действительно способен выполнять. Именно этот процесс компиляции и выполняют разработчики дистрибутивов (или сами авторы программ), прежде чем опубликовать готовый .deb-пакет, snap-пакет, или любой другой из уже изученных нами готовых форматов.

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

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

./configure — специальный скрипт (вспомните синтаксис ./ из предыдущего урока), который проверяет вашу конкретную систему: какие библиотеки и инструменты уже установлены, какая архитектура процессора используется, и готовит специальный файл-инструкцию (обычно называемый Makefile) для следующего шага, адаптированный именно под особенности вашей конкретной системы.

make — команда, которая на основе подготовленного `Makefile» непосредственно выполняет сам процесс компиляции — превращает исходный текст программы в реальный, исполняемый машинный код. Эта команда является частью более широкой системы автоматизации сборки, изначально разработанной ещё в 1970-х годах (снова вспомните исторический контекст урока 1.1 про раннюю эпоху UNIX) и остающейся актуальной по сей день для множества проектов.

sudo make install — финальный шаг, который копирует уже скомпилированные, готовые к использованию файлы программы из временной рабочей папки сборки в соответствующие системные папки (часто именно в уже знакомую нам по уроку 5.2 папку /usr/local», которая как раз специально предназначена в стандарте FHS для программ, установленных вручную подобным образом, в отличие от /usr», зарезервированной для программ, установленных через официальный пакетный менеджер дистрибутива).

Мы не будем подробно практиковать этот процесс в рамках данного вводного, ознакомительного урока — реальная сборка конкретных программ из исходного кода сильно варьируется в деталях в зависимости от конкретного проекта, требует установки дополнительных инструментов разработки (компиляторов и вспомогательных утилит, часто устанавливаемых через уже знакомый нам `apt install build-essential», который мы, кстати, уже упоминали как потенциальное решение проблемы с Guest Additions в уроке 2.7), и выходит за рамки базовой программы системного администрирования, являясь скорее темой, представляющей больший интерес для разработчиков программного обеспечения. Однако важно, чтобы вы концептуально понимали существование этого фундаментального уровня — того самого «первоисточника», из которого в итоге получаются все остальные, более удобные формы распространения программ, изученные в этом блоке.

Практика

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

Шаг 1. Проверьте, установлены ли базовые инструменты для компиляции в вашей системе: which gcc» (gcc — GNU Compiler Collection, один из самых распространённых компиляторов для языка C, разработанный в рамках уже хорошо знакомого нам проекта GNU из урока 1.3) и which make».

Что вы увидите: если инструменты не установлены (что вполне вероятно для базовой установки Ubuntu Desktop, не ориентированной специально на разработку), команда `which» не найдёт соответствующих путей.

Шаг 2. Если инструменты отсутствуют — установите базовый набор для компиляции, комбинируя материал этого урока с уже хорошо изученным APT: sudo apt install build-essential» (этот единый пакет-«сборник» включает в себя gcc, make» и другие необходимые для базовой компиляции инструменты одной установкой).

Шаг 3. Проверьте версию установленного компилятора: gcc --version» (используя уже знакомый нам по Блоку 4 универсальный параметр --version`).

[Скриншот терминала]

Шаг 4. Ознакомьтесь (не выполняя реальную компиляцию сложной программы) с общей структурой типичного процесса, который вы бы выполнили при наличии скачанного исходного кода реальной программы, подготовив в конспекте краткую пошаговую памятку из трёх шагов (./configure, make, sudo make install), основываясь на теории этого урока — это упражнение поможет закрепить понимание последовательности процесса, даже без его практического выполнения на конкретном примере.

Разбор команд

Команда make

• Назначение:** выполняет сборку (компиляцию) программы согласно инструкциям в файле `Makefile».
• Синтаксис:** make [опции] [цель]
• Реальные примеры использования:** помимо непосредственно компиляции программ из исходного кода, `make» широко используется и во множестве других контекстов автоматизации в разработке программного обеспечения — эта тема выходит за рамки данного курса, ориентированного на системное администрирование, но полезно знать о столь широкой распространённости этого инструмента в более широком мире IT.

Команда gcc

• Назначение:** компилятор языка программирования C (и, в расширенном варианте `g++», языка C++), преобразующий исходный код в исполняемый машинный код.
• Реальные примеры использования:** непосредственная работа с gcc» — это уже тема курсов по программированию, а не системному администрированию; в контексте нашего курса достаточно понимать, что именно этот (или аналогичный) инструмент незримо задействован на этапе make» при сборке программ из исходного кода.

Возможные ошибки

• Ошибка:** попытка компиляции сложной, современной программы без установки всех необходимых для сборки зависимостей (что концептуально отличается от зависимостей уже готовой, скомпилированной программы, изученных в уроке 9.1, — здесь речь идёт именно о зависимостях, необходимых на этапе самой компиляции).

Почему возникает: сборка из исходного кода часто требует не только базовых инструментов вроде gcc/`make», но и дополнительных библиотек и заголовочных файлов (специальных технических файлов с описанием интерфейсов библиотек, необходимых именно на этапе компиляции, а не только для последующего запуска готовой программы), специфичных для конкретного проекта.

Как определить: этап ./configure» или make» завершается ошибкой с указанием на отсутствующую конкретную библиотеку или инструмент.

Способы исправления: установить недостающую зависимость, которую (что приятно, замыкая круг материала этого блока) чаще всего можно найти и установить именно через уже хорошо знакомый нам `apt install», просто выполнив по указанному в сообщении об ошибке имени поиск подходящего пакета в репозиториях Ubuntu.

Как избежать: перед началом сборки сложной программы из исходного кода внимательно изучить сопроводительную документацию конкретного проекта (обычно файл README» или INSTALL» в папке с исходным кодом), где авторы программы, как правило, явно перечисляют все необходимые для успешной сборки зависимости.

Практические задания

1. Установите (если ещё не установлен) пакет build-essential» и проверьте версию gcc» в вашей системе, следуя шагам практики этого урока.
2. Составьте в конспекте итоговую сравнительную таблицу всех пяти изученных в этом блоке способов получения программ (APT/.deb, Snap, Flatpak, AppImage, сборка из исходного кода) по критериям: простота для новичка, скорость получения работающей программы, гибкость/контроль над процессом.
3. Своими словами объясните в конспекте, почему сборка из исходного кода считается «самым фундаментальным» способом получения программы среди всех пяти изученных в этом блоке подходов.

Проверка знаний

Вопрос 1. Что делает исходный код программы непригодным для непосредственного запуска процессором, и какой процесс это исправляет?

Ответ: Исходный код написан на языке программирования, понятном человеку, но не процессору напрямую. Процесс компиляции преобразует этот текст в машинный код, который процессор действительно способен выполнять.

Вопрос 2. В какую системную папку, согласно стандарту FHS, обычно устанавливаются программы, собранные вручную из исходного кода, в отличие от программ, установленных через официальный пакетный менеджер дистрибутива?

Ответ: В папку /usr/local», специально предназначенную в стандарте FHS именно для программ, установленных вручную, в отличие от /usr», зарезервированной для программ из официального пакетного менеджера.

Итоги урока

Вы изучили: концептуальный процесс сборки программы из исходного кода — ./configure, make, sudo make install, и понимание того, что именно этот процесс лежит в основе всех остальных, более удобных форматов распространения программ.

Вы умеете: устанавливать базовые инструменты для компиляции (build-essential) и понимаете общую логику трёхшагового процесса сборки.

В следующем уроке (это будет уже Блок 10) потребуется: весь накопленный в этом блоке материал об установке программ, чтобы разобраться, как эти программы запускаются и работают в системе как процессы и службы.

Мини-проект блока

Задача: закрепить владение всеми изученными в этом блоке подходами к установке программ, собрав небольшой практический «рабочий набор» из программ, установленных разными способами.

Что нужно сделать:

1. Установите одну полезную программу через классический APT (apt install).
2. Установите одну программу через Snap.
3. Установите (предварительно настроив) одну программу через Flatpak.
4. Если получится безопасно найти подходящий пример — скачайте и запустите одну программу в формате AppImage, предварительно придав ей право на выполнение.
5. Для программы, установленной через APT, дополнительно продемонстрируйте использование `dpkg -L» для просмотра списка её файлов.
6. Составьте в конспекте итоговую таблицу: название программы, способ установки, команда установки, и краткий личный вывод о том, каким способом вам было удобнее всего работать.
7. Аккуратно удалите все тестовые программы, установленные в рамках этого мини-проекта, каждую соответствующим её формату способом удаления (apt remove/purge, snap remove, flatpak uninstall, простое удаление файла для AppImage).

Критерий готовности: все четыре подхода опробованы на практике (или три, если AppImage не удалось безопасно опробовать), таблица заполнена, система очищена от тестовых установок.

Контрольные вопросы

1. Объясните понятия пакета, зависимости и пакетного менеджера.
2. В чём разница между apt update и apt upgrade? Почему их обычно выполняют именно в такой последовательности?
3. Объясните разницу между apt remove и `apt purge».
4. Как соотносятся между собой APT и dpkg? Какую задачу решает первый, но не умеет решать второй?
5. В чём принципиальное отличие подхода Snap/Flatpak от классического .deb-пакета?
6. Почему AppImage-файлы не требуют установки, и что нужно сделать перед первым запуском такого файла?
7. Какие три классические команды используются при ручной сборке программы из исходного кода, и что делает каждая из них?

Выводы по блоку

В этом блоке вы освоили полный спектр подходов к получению и установке программного обеспечения в Ubuntu — от классического, наиболее распространённого APT, через низкоуровневый dpkg» и работу с отдельными .deb`-файлами, до современных изолированных форматов Snap и Flatpak, портативного AppImage, и, наконец, фундаментального процесса сборки из исходного кода, лежащего в основе всех остальных подходов. Теперь вы способны осознанно выбирать подходящий способ установки конкретной программы в зависимости от ситуации, а не ограничиваться единственным знакомым инструментом.

Список изученных тем

• Понятия пакета, зависимости, пакетного менеджера, репозитория.
• APT: apt update, apt upgrade, apt install, apt remove, `apt purge».
• Низкоуровневый dpkg: установка .deb-файлов, разрешение зависимостей через `apt install -f».
• Snap: изолированные пакеты, команда `snap», Snap Store.
• Flatpak: альтернативный изолированный формат, команда `flatpak», Flathub.
• AppImage: портативные приложения, не требующие установки.
• Обзор сборки программ из исходного кода: ./configure, make, `make install».

Рекомендации перед переходом

Убедитесь, что вы уверенно владеете как минимум основным набором команд APT (update, upgrade, install, remove, `purge»), так как именно этот инструмент будет чаще всего использоваться на протяжении оставшихся блоков курса, например при установке служб и программного обеспечения для сервера (Docker в Блоке 17, Nginx и базы данных в Блоке 19). Понимание альтернативных форматов (Snap, Flatpak, AppImage) не обязательно применять активно прямо сейчас, но важно уверенно ориентироваться в них на случай, если конкретная нужная программа окажется недоступна через привычный APT.