Какого формата пакетов не существует для linux

Как установить программное обеспечение в Linux: объяснение форматов пакетов

Добро пожаловать в Linux. Скорее всего, ваш дистрибутив поставляется с большим количеством программного обеспечения, чтобы охватить основы. Тем не менее, независимо от того, насколько тщательной была работа, вы хотите установить больше. Вопрос в том, как?

Установка программного обеспечения на Linux чувствует себя ближе к смартфону, чем Windows. В большинстве случаев вы будете запускать менеджер пакетов (похожий на магазин приложений) и искать название нужного вам приложения. Оттуда, это вопрос нажатия кнопки установки.

Но менеджеры пакетов меняются в зависимости от вашего дистрибутива. Ubuntu использует программное обеспечение Ubuntu. Это просто переименованная версия программного обеспечения GNOME, которую использует Fedora. Тем временем openSUSE делает свое дело с YaST.

Менеджеры пакетов работают с помощью поиска в репозиториях вашего дистрибутива. Но иногда того, чего вы хотите, там нет. Иногда вы загружаете файл с веб-сайта и нажимаете на него, как если бы это был файл Windows EXE. За исключением того, что есть проблема. Точно так же, как нет единой версии Linux, не существует единого универсального формата пакета Linux ( хотя некоторые люди пытаются изменить этот ).

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

DEB Пакеты

Формат DEB получил свое название от Debian, дистрибутива Linux и одного из крупнейших существующих проектов с открытым исходным кодом. Вы можете щелкнуть DEB, чтобы установить приложение напрямую, или выполнить поиск в диспетчере пакетов, чтобы он выполнил работу за вас в фоновом режиме. В терминале вы используете команду dpkg , например:

Поскольку Ubuntu основана на Debian, DEB легко найти. С миллионами пользователей и узнаваемым именем Ubuntu и DEB стали Windows и EXE-файлами в мире Linux.

Debian и Ubuntu оба используют формат файла DEB, но пакеты, которые работают в одном, могут не работать в другом. Пакеты иногда совместимы с обоими, например с Google Chrome. Не думайте, что это так. Убедитесь, что вы загружаете DEB, предназначенные для вашего дистрибутива.

Популярные дистрибутивы, использующие DEB:

• Ubuntu
• Debian
• Linux Mint
• SteamOS
• Trisquel
• gNewSense

RPM пакеты

RPM изначально обозначал Red Hat Package Manager. Теперь аббревиатура является рекурсивной и расшифровывается как RPM Package Manager. В любом случае, происхождение связано с Red Hat. Организация из Северной Каролины, которая стала первой в мире компанией с открытым исходным кодом на миллиард долларов, разработала формат для Red Hat Linux. В результате, это то, что вы найдете в экосистеме Red Hat.

Это означает, что если вы , это тип файла пакета, который вы будете использовать для установки программного обеспечения. Когда вы нажимаете на RPM, он открывается в программном обеспечении GNOME.

Несмотря на название, дистрибутивы, связанные с Red Hat, не единственные, которые используют RPM. openSUSE — еще одно известное сообщество, принявшее RPM Вы можете установить их с помощью YaST, универсального дистрибутива для управления большинством систем.

В любом случае вы можете установить пакеты с помощью команды rpm , например:

Fedora и openSUSE используют RPM, но пакеты не являются взаимозаменяемыми. Опять же, убедитесь, что загружаемый вами RPM предназначен для вашего дистрибутива.

Популярные дистрибутивы, использующие RPM:

• Red Hat Enterprise Linux
• мягкая фетровая шляпа
• OpenSUSE
• SUSE Linux Enterprise Server
• CentOS
• PCLinuxOS

Пакеты TAR

Я знаю, что сказал, что нет универсального формата пакетов для Linux, но это не на 100% верно. Когда вы видите приложение, упакованное как TAR, TGZ или TAR.GZ, есть большая вероятность, что оно будет работать на вашем компьютере. Проблема в том, что установка не так проста, как наведение курсора или ввод одной команды. Установка файла TAR заслуживает отдельного руководства

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

Популярные дистрибутивы, которые используют исключительно TAR:

• Arch Linux
• Slackware

Больше, откуда это пришло

Три перечисленных выше типа не являются единственными форматами пакетов для Linux, но они являются наиболее распространенными. Некоторые дистрибутивы разрабатывают свои собственные типы, которые не используются в других местах. Gentoo имеет ebuild . В Pardus есть PiSi (сокращение от «Пакеты, успешно установленные по назначению»). Android, технически дистрибутив Linux, использует APK.

Почему форматы пакетов такие странные?

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

Что вы думаете об установке программного обеспечения в Linux? Как это по сравнению с другими операционными системами? Можно ли это улучшить? Поделитесь своими мыслями, и если у вас есть какие-либо вопросы, не стесняйтесь спрашивать!

какого формата пакетов не существует для linux

Пригодная для работы пользователя система состоит из множества (сотен и тысяч) программ и утилит. В Linux каждый компонент системы представлен в виде пакета. Все операции, связанные с изменением состава системы: установка, удаление, проверка, обновление компонентов, — производятся над пакетами. В целом, пакет — это средство сделать так, чтобы пользователь-администратор, изменяя или обновляя программное наполнение системы, работал не с файлами (имена которых ему подчас неизвестны), а с определёнными функциональностями самой системы: например, добавлял в неё не «500 файлов», а «WWW-сервер apache ».

Архив файлов

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

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

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

tar появился намного раньше Linux и изначально служил для создания файловых архивов на магнитной ленте. Отсюда и его название — tape archiver, «архиватор для (магнитных) лент». В настоящее время tar присутствует в любой UNIX-подобной системе и позволяет работать с файловыми архивами на любых носителях.

С каждым указанным каталогом tar работает рекурсивно, т. е. запаковывает все содержащиеся в нём файлы и подкаталоги.

При распаковке архива tar файлы извлекаются вместе с путём, недостающие подкаталоги создаются по мере необходимости. Все пути tar считает относительными от своего рабочего каталога. Если теперь Мефодий распакует свой архив (командой « tar xf имя_архива »), то в рабочем каталоге будет создан подкаталог « bin/ » и в него будут записаны все файлы из архива.

Ключ « v » велит tar быть «разговорчивым» (verbose), т. е. выводить больше диагностичских сообщений, блаодаря этому tar при распаковке выводит имена (с путём) всех записываемых файлов. Если в рабочем каталоге уже есть файл, который tar собирается создать при распаковке, то этот файл будет попросту заменён файлом из архива. Так, когда Мефодий распаковал свой архив, подкаталог « bin/ » со всем его содержимым заменился на подкаталог из архива. В данной ситуации это не страшно, поскольку в архиве файлы такие же, но вот если бы Мефодий перед распаковкой изменил какие-то из своих файлов в « bin/ », он лишился бы всех изменений.

Формат пакета

Регистрация в системе

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

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

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

Можно выполнить и обратную процедуру — выяснить про любой файл, какому пакету он принадлежит:

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

Система Linux раскладывается на компоненты без остатка: каждый файл в Linux принадлежит какому-нибудь (и только одному!) пакету.

Естественно, кроме тех файлов, которые созданы пользователями.

Изменение настроек системы

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

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

Мефодий выяснил, что сценарии в пакете coreutils запускаются перед началом установки (preinstall), после установки (postinstall) и перед удалением (preuninstall), они выполняются стандартным командным интерпретатором ( /bin/sh ). Все эти сценарии нужны для того, чтобы зарегистрировать в системе info установленную пакетом документацию или удалить эту документацию из системы (командами /usr/sbin/install_info и /usr/sbin/uninstall_info соответственно). Поскольку info строит общее оглавление всей имеющейся в системе документации, простого копирования файлов было бы недостаточно.

В результате подобных операций по интеграции пакета в систему могут быть изменены или удалены файлы, не принадлежащие данному пакету, созданы новые файлы. Если программа, содержащаяся в пакете, пользуется услугами какой-нибудь уже установленной службы (например, syslogd ), может понадобиться регистрация этой программы в конфигурационных файлах службы. Конечно, изменение «чужих» файлов в процессе установки пакета нежелательно: впоследствии, удаляя пакет, потребуется вернуть файл в исходное состояние, что не всегда возможно (например, после вдумчивого редактирования администратором). Избежать редактирования конфигурационных файлов позволяет схема «. d», описанная в лекции Этапы загрузки системы.

Цена удобства

Удобство, которое получает пользователь при работе с пакетами достигается не само собой, а человеческим трудом: пакеты должен создавать человек, его работа называется «сопровождающий» («package maintainer» или «packager»). В обязанности сопровождающего пакет входит подготовка файлового архива, необходимых для установки и удаления сценариев и прочей информации о пакете и его содержимом, и объединение их в одном файле-пакете.

Нужно принимать во внимание, что любой пакет, содержащий программное обеспечение для Linux, не является универсальным. Если у вас есть такой пакет, это ещё не означает, что его можно установить в вашей системе. Дело в том, что разные дистрибутивы Linux различаются именно тем, каким образом программное обеспечение организовано в систему (о дистрибутивах речь пойдёт в лекции Политика свободного лицензирования. История Linux: от ядра к дистрибутивам). Дистрибутивы могут различаться размещением файлов и процедурами, предусмотренными для интеграции в систему программного обеспечения, не говоря уже о том, что в разных дистрибутивах используется разный формат пакетов. Это значит, что пакет, подготовленный с ориентацией на один дистрибутив, может оказаться несовместимым с другим. Чтобы в вашем дистрибутиве появилась некоторая программа, кто-то должен подготовить и сделать доступным соответствующий пакет.

пакет Ресурсы, необходимые для установки и интеграции в систему некоторого компонента (архив файлов, до- и послеустановочные сценарии, информация о пакете и его сопровождающем), объединённые в одном файле.

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

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

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

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Умение устанавливать, обновлять и удалять программное обеспечение относится к важнейшим навыкам работы с любой операционной системой. Поэтому изучение данного вопроса первостепенная задача для любого начинающего пользователя Linux, сразу после того, как он немного осмотрелся в системе. К сожалению, нет единого способа управления ПО, подходящего для всех дистрибутивов, разные семейства предполагают различные подходы, хотя общие принципы во многом совпадают. В данном материале мы будем разбирать вопрос применительно к системам основанным на Debian и Ubuntu.

Пакеты и репозитории

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

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

Кроме того, установка пакетов в обход репозитория может быть небезопасна и считается правилом дурного тона, хотя и применяется, в основном для коммерческого ПО. Наличие репозиториев также позволяет централизованно обновлять пакеты, достаточно сравнить текущие версии пакетов с версиями в репозитории и скачать нужные обновления. Это удобно, так как одновременно обновляется и система и все установленное в нее ПО.

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

Как правило типичный дистрибутив на базе Debian имеет четыре основных репозитория:

Каждый репозиторий состоит из нескольких разделов, в Debian это:

В Ubuntu разделы немного иные:

Список подключенных репозиториев хранится в /etc/apt/sources.list, ниже показано содержимое этих файлов в Debian 10 (слева) и Ubuntu 18.04 (справа).

В Debian все достаточно лаконично, подключен только раздел main трех репозиториев Base, Security updates и Stable updates, если вам нужны иные разделы, то их следует подключить самостоятельно, добавив через пробел в нужную строку.

В Ubuntu более развернутый список репозиториев, он полностью не уместился на скриншот, но для понимания структуры записей приведенного фрагмента хватает. Сверху вниз подключены Base и Security updates для поддерживаемых компанией разделов, затем они же вместе для свободного и несвободного ПО поддерживаемого сообществом, а вот Stable backports прописан для всех веток одновременно, еще ниже (за пределами экрана на скриншоте) подключены Security updates и специальный партнерский репозиторий для пакетов партнеров компании Canonical.

Типичная запись репозитория выглядит как строка со следующей структурой:

Адреса репозиториев сохраняются постоянными, отличаясь только именами выпуска, поэтому если вам нужно обновить выпуск, скажем с Debian 9 на Debian 10, то вам просто потребуется заменить везде stretch (имя девятого выпуска) на buster.

Также в Debian можно использовать вместо имен классы выпусков:

Но на практике это не используется, так как при выходе нового релиза вы получите его автоматическое обновление, что в большинстве случаев неприемлемо. Хотя если вы энтузиаст и хотите всегда быть на переднем крае прогресса, то можете везде прописать testing, получив аналог популярных ныне rolling release дистрибутивов, которые не имеют закрепленной версии и всегда предоставляют наиболее свежий срез пакетов, зачастую ценой стабильности.

Для добавления собственных источников пакетов предназначена директория /etc/apt/sources.list.d/ в которой следует располагать файлы с адресами источников и обязательным расширением .list. Хотя их можно прописать и в основной файл, но это считается дурным тоном.

Низкоуровневый менеджер пакетов Dpkg

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

Для установки просто выполните:

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

Такая конструкция установит все находящиеся в данном расположении deb-пакеты, так что будьте внимательны, либо используйте более узкие маски.

Чтобы получить сведения о всех доступных и установленных пакетах используется ключ -l, но он выведет список всех пакетов, поэтому следует использовать его с маской, например, так:

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

Теперь мы видим больше пакетов, как установленных в системе, так и доступных в репозитории. Но это не все пакеты, относящиеся к gimp, так как наша маска предписывает искать пакеты, которые начинаются на gimp и игнорирует иные варианты. Поэтому, если вы не уверены, что правильно задали маску, можно пойти другим путем, отдав вывод dpkg команде grep, которая найдет все нужные вхождения.

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

Для удаления пакета используйте:

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

Но будьте внимательны, при этой операции могут быть удалены пользовательские данные, хранившиеся в стандартных расположениях. Это актуально для таких видов программ, как веб-сервера или СУБД.

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

Улучшенный инструмент для работы с пакетами APT и команды apt и apt-get

Настоящим пакетным менеджером в Debain является APT (Advanced Package Tool, Улучшенный инструмент для работы с пакетами), который умеет работать с репозиториями, разрешать зависимости и взаимодействовать с dpkg, которая, собственно, и занимается установкой пакетов.

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

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

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

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

Установить обновления можно командой:

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

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

Обычные обновления следует выполнять командой upgrade, тогда как dist-upgrade следует использовать для обновления дистрибутива, в том числе и на минорные версии в составе текущего выпуска.

Для установки пакетов следует использовать команду:

Если нужно установить несколько пакетов, то их следует перечислить через пробел. Система проанализирует изменения и либо выполнит установку, либо попросит дополнительного подтверждения, особенно если нужно установить большое количество новых пакетов по зависимостям.

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

Для удаления пакета используйте:

Это удалит сам пакет, но оставит его конфигурационные файлы (если они были изменены) и прочие данные. Для полного удаления пакета со всеми его данными используйте другую команду:

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

Дополнительно остановимся на таком виде пакетов, как пакеты установленные автоматически. Это пакеты, которые были установлены по зависимостям иных пакетов и после удаления или обновления последних могут более никем не использоваться. APT отслеживает такие пакеты и сообщает о них пользователю.

Удалить их можно командой:

Как можно заметить, APT достаточно дружелюбен к пользователю, постоянно подсказывая ему необходимые команды, что в очередной раз развеивает миф о сложности администрирования Linux, особенно в режиме командной строки.

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

Эта команда полностью очистит кеш, также можно использовать более мягкую очистку с помощью apt-get, который дает возможность удалить из кеша только те пакеты, которые на текущий момент отсутствуют в репозитории (были заменены новыми версиями или удалены):

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

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

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

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

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

Для получения информации о пакете просто введите:

Чтобы отменить фиксацию выполните:

Объем данной статьи не позволяет рассмотреть все возможности apt, поэтому мы ограничились наиболее необходимыми в повседневной деятельности, ну и в завершение небольшая порция юмора. Если запустить команду apt без параметров, то вы увидите краткую справку в самом конце которой будет строка: В APT есть коровья СУПЕРСИЛА. Что это значит? Просто наберите:

И вы увидите старую пасхалку от разработчиков, которая была еще в apt-get, а затем ее заботливо перенесли в apt.

Графические оболочки Aptitude и Synaptic

Кроме родных для APT консольных интерфейсов apt-get и apt существуют и более высокоуровневые оболочки. Одна из них aptitude, которая может работать как в псевдографическом режиме, так и в режиме командной строки, имея синтаксис во многом повторяющий синтаксис apt. Благодаря этому многие воспринимают эту утилиту как еще один интерфейс к APT, хотя основной задачей разработчиков было именно создание псевдографической интерактивной оболочки.

В современных дистрибутивах Debian и Ubuntu aptitude отсутствует в основной поставке и вам потребуется установить этот пакет отдельно.

Если вы используете настольную версию Linux, то вам будет доступен графический менеджер пакетов Synaptic, он также отсутствует в основной поставке основных дистрибутивов и может быть установлен вручную. Данный пакет представляет собой опрятный и удобный графический интерфейс над APT, в тоже время дающий администратору все возможности по тонкой настройке процесса.

Однако не смотря на то, что Aptitude и Synaptic являются зрелыми и эффективными инструментами, мы бы не рекомендовали их использование по крайней мере до тех пор, пока вы не освоите работу с базовым интерфейсом apt.

Магазины приложений

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

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

Ниже показан магазин для актуальной версии Debian

Заключение

Как видим, Debian и основанные на нем системы предоставляют широкий выбор инструментов для управления пакетами, начиная от утилит командной строки и заканчивая магазинами приложений. Каждый найдет инструмент себе по душе. Но для начинающих администраторов мы бы рекомендовали в обязательном порядке осваивать базовые инструменты, такие как dpkg и apt, потому что ситуации бывают разные, а базовые инструменты, в отличие от графической оболочки или псевдографических утилит, доступны всегда.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Пакеты и форматы (вопросы от новичка)

Здравствуйте, товарищи! Я тут новенький, поэтому кратко о себе. С компом дружу более 35 лет, помню ещё компы с загрузкой игр с аудиокассет. Преимущественно общался с Виндой (ну и с MS-DOS вначале). С пингвином стал дружить лишь недавно. На ноуте уже лет пять как стоит Мята, пользуюсь не очень часто, но пользуюсь. В будущем планирую полностью перебраться на Линь, видимо на Debian. Параллельно время от времени изучаю Линукс как таковой. Тема за темой, не торопясь. И вот сейчас появилось свободное время, продолжил изучение. Взял тему пакетов и их форматов. Составил табличку (см. прикреп. файл … Не нашёл где тут добавляется картинка, так что вот ссылка на Гугл-диск: https://drive.google.com/file/d/1t2T8ahmIVYAJ7oBx6a2vska9Vm8Fx1aX/view?usp=sharing). Но. В интернете просто писец какой-то происходит. Чуть ли не каждый второй сайт путает понятия системы управления пакетами и пакетного менеджера. Открываешь какой-нибудь сайт, а там табличка и в графе «пакетный менеджер» написано DPKG (а это СУП!), а потом через запятую вообще flatpack (а это формат пакета!). Охренеть! И из-за этой вот путаницы я несколько дней потратил, чтобы эту табличку хоть как-то составить. Наверняка, в ней есть ошибки…

1. Посмотрите кому не лень табличку и определения в целом, всё ли верно? Подозреваю, что там немало неточностей, т. к. инфу рыл долго и мучительно «с сайта по нитке». В частности, у меня сомнения по поводу Slackpkg. Неужели, она не используется в Slackware? Уж больно похожи названия.
2. Из таблички получается, что у Solus есть три пакетных менеджера — eopkg, snapd и flatpak. Причём, первый работает и с форматом flatpak, и с форматом snap, второй только со snap, а третий только с flatpak. Верно ли это?
3. Заполните пробелы (красные знаки вопроса) в табличке.
4. Правильно ли я понимаю, что tar.gz = TGZ, tar.xz = TXZ, а сами TGZ и TXZ — разновидности TAR?
5. Бинарник и исходник это же разные понятия? Исходник это SRC, а бинарник это какое расширение\формат? Знаю, что в Линуксе расширения не важны, но для ориентира они всё же есть.
6. Верно ли, что менеджеры APT, APM, Synaptic, Gnome software и Appgrid (т. е. все те, что относятся к системе DPKG) работают без проблем на любом дистрибутиве семейства Debian?

snap и flatpak есть практически в любом дистрибутиве, это «универсальные пакеты»

pacman, zypper, emerge, в Slax не Slackpkg, и в OpenSuse тоже, eopkg

tar — архиватор, xz/xz сжатие

Бинарник скомпилированный файл, в unix не имеет расширения, аналог .exe, исходник, это кож программы https://github.com

По теме, викторина какая-то. Ты занимаешься полной чушью и знания такие тебе не нужны. Есть еще пол сотни дистрибутивов со своими пакетными менеджерами, которые в таблице не указаны.

Пакетный менеджер — это калька с английского. Он же СУП.

1. Есть неточности.
2. tar.gz = tgz. Это tar, запакованый gz, а не разновидность тар.
3. Разные. Если речь про типы пакетов, то исходник — это файлы + инструкции, необходимые для создания бинарника. Бинарник — то, что попадет в систему при установке + инструкции для установки.
4. В общем случае нет. Совсем без проблем не бывает.

tar.gz = TGZ, tar.xz = TXZ, а сами TGZ и TXZ — разновидности TAR

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

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

1. Убунту работает на deb/apt, «семейство ред-хат» на rpm. Как уже выше писали, snap и flatpak ставятся на многие дистрибутивы. В snap и flatpak нет системных компонентов, хотя есть маргинальные дистры, которые пытаются их туда запихнуть. В Gentoo вместо пакетов с программами — «ебилды», где не содержится программа, а только информация откуда скачать ее исходник и как скомпилировать. Gnome Software по идее обертка над apt. Короче творят что хотят и болт клали на эти логические построения)

Параллельно время от времени изучаю Линукс как таковой.

Судя по тексту — пока ещё нет.

В будущем планирую полностью перебраться на Линь, видимо на Debian.

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

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

Сразу скажу, движение от общего к сути — очень плохая затея. Гораздо эффективнее выбрать что-то и далее, отбросив всякое дистрохопперство, хорошенько освоить, обжить, заставить работать на себя и по возможности реализовать все свои хотелки. Где-то на этом пути многие твои сегодняшние вопросы будут закрыты или отпадут.

К сожалению тут возникает порочный круг. Как можно сделать правильный выбор, если не хватает знаний, а чтобы получить знания, надо сделать выбор?! Хорошего решения не существует. Тебе придётся сделать выбор опираясь на мифы и рекламу, отбросить сомнения хотя бы на какое-то приличное время (год-два), и приступить.

На закуску ещё одна плохая новость: у одного человека нет никаких шансов понять весь линукс, точно также как у него нет никаких шансов жить одновременно в нескольких местах, спать одновременно в разных постелях и тд.

От себя намекну. Когда все говорят, что нечто говно, присмотрись к этому явлению повнимательнее 😉

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

Когда все говорят, что нечто говно, присмотрись к этому явлению повнимательнее

Мдя. Я вот так навскидку не могу придумать совета хуже. В подавляющем количестве случаев, говно это всего лишь говно и окружающие это видят. О чём и говорят.

В подавляющем количестве случаев, говно это всего лишь говно

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

В целом я, таки, разобрался. Как ни странно. Думал, будет в итоге больше вопросов, чем ответов. Но нет, всё более-менее улеглось в голове. Что осталось по мелочи:

Ты занимаешься полной чушью и знания такие тебе не нужны

Нужны. Долго писать, объяснять. Если интересно, напишу.

Там, кстати, тоже путают понятия backend-a и frontend-a. Но я, кажется, понял, почему так. Это зависит от дистрибутива — в некоторых (Дебиан, Убунту, Минт) разделение на СУП и менеджеры реально обосновано кодом и логикой, т. е. объективно существует, а в других этого разделения нет.

С бинарником значит, как в Винде, проще говоря? Скомпилированная прога, готовая к исполнению. А скриптовые проги не компилируются (это как язык Autohotkey на Винде). Только почему называется «бинарник»? Там ведь не единички и нолики, т. е. это не первичный машинный код? Или это таки он?

Какие СУПы в Slax и OpenSUSE?

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

Сразу скажу, движение от общего к сути — очень плохая затея.

Я не собираюсь весь свой Линукс-путь так двигаться. Но для начала, только так и можно. Опять же, долго объяснять. Если надо, напишу подробнее.

Есть еще пол сотни дистрибутивов со своими пакетными менеджерами, которые в таблице не указаны.

А мне все и не нужны. Только основные. Для понимания и погружения в тему.

если дистрибутив выбирается под цель, под задачи, а они у каждого свои?

Дык я ж не протестую, но мнение имею.

Но для начала, только так и можно.

Для начала хватит rpm+dnf vs dpkg+apt.

Доброго утречка! Ещё вопросы по теме:

1. Если у исполняемого файла нет расширения, то как вы узнаёте, какой из файлов в папке является исполняемым? Не будешь же смотреть свойства по каждому. Полагаю, представление в виде таблицы решает вопрос, или как?
2. Пакет – это архив. Это работает как и в Винде? Т. е. в Винде есть, например, RAR или ZIP. Я могу разархивировать RAR, получить файлы из архива. Затем эти же файлы заархивировать уже как ZIP. Работает ли это с пакетами Линукса, т. е. могу ли я разархивировать, к примеру, DEB и потом его файлы заархивировать как TAR?
3. Перечень основных форматов пакетов: DEB, RPM, TAR (TGZ, TXZ, TBZ, TLZ), SNAP, FLATPAK, APK. Менее популярные: ZST, LZM, PiSi, MO, PUP, PET. Все ли я назвал?
4. Ну и из предыдущего моего письма (про СУПЫ Slax и OpenSUSE и др.).

Вы задаёте неправильные вопросы. Надо спрашивать (самого себя?) «зачем и почему», а не «как». Мои 2 копейки.

Для начала хватит rpm+dnf vs dpkg+apt

Не, я о другом. Видимо, надо объяснить всё-таки. Я обучаюсь всегда в два основных этапа: 1. Получение общих системных (академических) знаний о предмете (индуктивный принцип), 2. Применение знаний на практике, эксперименты, опыты, (дедуктивное обучение). Т. е. я не могу оперировать понятиями, не имея о них базового знания. Это как с написанием программы: нужно сначала объявить переменную, сказать компу, какого она типа, и только потом комп сможет её применять. Если объявить ему, что переменная «а» имеет тип abrakadabra, он скажет, что не знает такого, и вся программа работать не будет. Или это можно сравнить с тем, что я отправляюсь в лес с волками, имея лишь перочинный ножик. Куда лучше иметь некую элементарную базу (хотя бы кожаную броню, охотничий нож и фонарик) — та база, которую я должен получить ДО того, как начну идти дедуктивным путём (от меньшего к большему). И уже потом, в процессе прогулки, можно найти броню покрепче, пистолет, лазер и т. д.. У меня так во всём. Где бы ни работал, чем бы ни занимался, всегда сначала изучаю общую структуру. Это академический подход. Он более медленный, но имеет преимущества. Например, позволяет при наличии проблемы более точно предугадать её источник и быстрее решить её (т. к. структурные знания позволяют не гадать «что это может быть», а сразу сказать, что «тут, скорее всего, дело в том-то». Собственно, именно поэтому, этот принцип лежит в основе любого институтского образования. И я не раз убеждался в том, что это работает. Ну а когда я пойму, что в голове сложилась базовая структура того, что такое Линукс и с чем его едят, можно будет уже экспериментировать и дальше уже идти точечно.

С бинарником значит, как в Винде, проще говоря?

Принципиальное отличие линукса от винды в подходе к скриптам.

Скомпилированная прога, готовая к исполнению. А скриптовые проги не компилируются (это как язык Autohotkey на Винде). Только почему называется «бинарник»? Там ведь не единички и нолики, т. е. это не первичный машинный код? Или это таки он?

Заголовочная информация. В винде это обычно PE, в линуксе обычно Elf. Определённые мета-данные.

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

Собственно тот самый машинный код.

В этом плане и винда и линукс работают примерно одинаково.

Бинарник наверное потому, что всё вышеперечисленное хранится в бинарном виде и если открыть в блокноте, то увидишь в основном белиберду.

Хотя в винде есть скрипты, но тебе при их запуске нужно вручную указывать программу-интерпретатор. explorer позволяет это делать автоматически, но это не уровень ОС. В линуксе на уровне ОС есть поддержка скриптов, когда первой строчкой в файле написано #!/some/path\n, то запускается этот самый /some/path с параметром-именем файла, причём это работает полностью прозрачно для всех программ. Это принципиальное отличие.

Доброго утречка! Ещё вопросы по теме:

Если у исполняемого файла нет расширения, то как вы узнаёте, какой из файлов в папке является исполняемым? Не будешь же смотреть свойства по каждому. Полагаю, представление в виде таблицы решает вопрос, или как?

У каждого файла есть права доступа. read/write/execute. Если проставлено право execute, то его можно выполнить. Права можно просмотреть командой ls -l

Пакет – это архив. Это работает как и в Винде? Т. е. в Винде есть, например, RAR или ZIP. Я могу разархивировать RAR, получить файлы из архива. Затем эти же файлы заархивировать уже как ZIP.

В линуксе традиционно отличают архивацию от сжатия. Архивация это tar. Можно представить себе его как zip без сжатия. Т.е. это некие заголовки с именами файлов и некоторой другой информацией плюс содержимое файлов и всё это в одном файле. file.tar. Иными словами на входе множество файлов и каталогов, на выходе один файл. А есть программы для сжатия. gzip, bzip2, xz. Они просто сжимают данные. Т.е. на входе один файл, на выходе один файл. А вместе tar + gz, например, делают то же, что делает zip или rar.

Работает ли это с пакетами Линукса, т. е. могу ли я разархивировать, к примеру, DEB и потом его файлы заархивировать как TAR?

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

Урок #28. Пакеты, репозитории и другие термины

Я решил сделать теоретическое отступление и объяснить некоторые термины, которые можно встретить довольно часто при поиске информации по работе с семейством операционных систем Линукс.

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

Термин «пакет» может иметь два смысла. Во-первых, пакетом могут называть набор исходных текстов программы, который создали разработчики. То есть это сам код программы, написанный на некотором языке программирования и такие тексты называют исходниками. Но для того чтобы программа заработала ее нужно скомпилировать, то есть превратить исходный текст в исполняемый файл (файлы). Такие пакеты называют бинарниками и этот термин можно услышать тоже очень частот. Работая с Линукс мы будем иметь дело именно с такими пакетами.

Бинарные пакет могут иметь разные форматы и могут отличаться для разных дистрибутивов Linux. В Linux Mint используется формат deb и пакеты, предназначенные для Linux Mint в большинстве случаев совместимы с пакетами дистрибутивов Ubuntu и Debian.

Дистрибутив операционной системы Linux или какой-либо программы представляет собой комплект скомпелированных из исходников исполняемых и всех дополнительных файлов, собранных по определенным принципам. Этот процесс сборки пакетов логично называется «сборкой» или от английского «майнтейном», а людей, которые это делают называют, соответственно, майнтайнерами.

Дополнительный файлы или пакеты, необходимые для работы основного пакета, называют зависимостями. Объяснить это важное понятие можно так. Поскольку лицензия использования Linux подразумевает открытость исходных кодов, то при написании программы разработчик опирается на функционал созданного ранее другим разработчиком пакета. В результате для работы вновь созданного пакета, требуется наличие пакета другого разработчика (или созданного ранее пакета). В свою очередь второй пакет для своей работы может требовать наличие еще каких-то пакетов, и так далее.

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

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

Библиотеки для нас, как для обычных пользователей, не представляют никакого интереса. Зато они очень сильно помогают разработчикам программ. Дело в том, что есть масса стандартных, типовых действий, которые свойственны всем или большинству программ. Например, открытие/закрытие файла, его сохранение, отрисовка окна программы и его графических элементов и так далее… Эти действия и элементы в плане программирования ничем не отличаются и нет смысла их создавать каждый раз для каждой отдельной программы. Все эти участки программного кода вынесены в специальные программные модули, которые и называются библиотеками. Именно это позволяет программистам не дублировать одно и то же в своих программах, а пользоваться одной единственной библиотекой на всех. Достаточно чтобы такая библиотека была установлена в системе и все программы для своей работы будут использовать ее.

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

Для хранения пакетов существуют специальные хранилища — репозитории. Репозитории, как я уже упоминал в одном из предыдущих видео, ориентированы на конкретные дистрибутивы, а для некоторых дистрибутивов Линукс можно использовать репозитории других дистрибутивов, так как пакеты этих дистрибутивов совместимы. Так, например, обстоит дело в случае с Linux Mint и Ubuntu.

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

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

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

Установщиков существует множество и об одном из них (Менеджере программ) речь шла в прошлом видео. Менеджер программ Linux Mint является очень простой утилитой для работы с пакетами. В следующем видео я расскажу о более функциональном менеджере пакетов Synaptic.