Как получить список файлов, установленных из пакета RPM или DEB в Linux
Вы когда-нибудь задумывались, где различные файлы, содержащиеся в пакете, установлены (находятся) в файловой системе Linux? В этой статье мы покажем, как составить список всех файлов, установленных или присутствующих в определенном пакете или группе пакетов в Linux.
Это может помочь вам легко найти важные файлы пакетов, такие как файлы конфигурации, документация и многое другое. Давайте рассмотрим различные методы перечисления файлов в пакете или установленных из пакета:
Как получить список всех файлов установленного пакета в Linux
Вы можете использовать yum-utils для вывода списка файлов, установленных в системе CentOS/RHEL из данного пакета.
Чтобы установить и использовать yum-utils, выполните следующие команды:
# yum update # yum install yum-utils
Теперь вы можете перечислить файлы установленного пакета RPM, например веб-сервера httpd (обратите внимание, что имя пакета чувствительно к регистру). Флаг —installed означает, что пакеты установлены, а флаги -l включают список файлов:
# repoquery --installed -l httpd # dnf repoquery --installed -l httpd [On Fedora 22+ versions]
Важно: в версии Fedora 22+ команда repoquery интегрирована с менеджером пакетов dnf для дистрибутива на основе RPM для отображения файлов, установленных из пакет, как показано выше.
Кроме того, вы также можете использовать приведенную ниже команду rpm для вывода списка файлов внутри или установленных в системе из пакета .rpm следующим образом, где -g и -l означает список файлов в пакете:
# rpm -ql httpd
Еще одна полезная опция — использовать -p для просмотра списка файлов пакета .rpm перед его установкой.
# rpm -qlp telnet-server-1.2-137.1.i586.rpm
В дистрибутивах Debian/Ubuntu вы можете использовать команду dpkg с флагом -L , чтобы получить список файлов, установленных в вашей системе Debian или ее производных, из заданного . пакет deb .
В этом примере мы перечислим файлы, установленные с веб-сервера apache2:
$ dpkg -L apache2
Не забудьте ознакомиться со следующими полезными статьями по управлению пакетами в Linux.
- 20 полезных команд Yum для управления пакетами
- 20 полезных команд RPM для управления пакетами
- 15 полезных APT-команд для управления пакетами в Ubuntu
- 15 полезных команд Dpkg для Ubuntu Linux
- 5 лучших менеджеров пакетов Linux для новичков в Linux
Вот и все! В этой статье мы показали вам, как получить список/найти все файлы, установленные из данного пакета или группы пакетов в Linux. Поделитесь с нами своими мыслями, используя форму обратной связи ниже.
Все права защищены. © Linux-Console.net • 2019-2023
Правильно пакетим ПО для Linux
Одной из самых важнейших проблем для разработчика в мире Linux является создание правильных пакетов. Это обычно вызывает множество вопросов, поэтому в данной статье мы решили подробно их разобрать.
Введение
Большинство разработчиков считают, что правильным является создание одного RPM и одного DEB пакета, однако это в корне неверно. Как RPM, так и DEB являются лишь контейнерами с метаданными для того, что находится у них внутри.
В каждом дистрибутиве RPM/DEB пакеты имеют свои, зачастую ни с кем не совместимые, особенности. Также каждый дистрибутив имеет совершенно разные наборы и версии библиотек.
Например если мы соберём пакет в Fedora 29 и динамически привяжемся к Qt 5.11 или ffmpeg 4.0, то он в большинстве случаев не будет работать в более старой версии Fedora 26 с Qt 5.6 и ffmpeg 3.1. Это же касается и Debian/Ubuntu. Обратная совместимость API/ABI внутри библиотек работает обычно лишь в более новых версиях относительно старых, однако некоторые на неё вообще забивают.
Также RPM пакет, собранный для Fedora, скорее всего не будет работать в openSUSE или ALT Linux, поэтому если и собирать пакеты, то это нужно делать для каждого дистрибутива в отдельности и в пределах как минимум двух поддерживаемых версий.
Способы линковки
Существует два способа компоновки приложения с необходимыми ему библиотеками:
- динамическая — компоновщик линкует бинарник с уже существующими в системе динамическими библиотеками. При запуске они подгружаются в адресное пространство;
- статическая — все необходимые зависимости вшиваются внутрь бинарника статически.
Каждый способ имеет как достоинства, так и недостатки. Рассмотрим их более подробно.
Динамическая линковка
- позволяет использовать разделяемую память библиотек, т.е. если какое-то запущенное приложение уже использует её, она не дублируется в памяти, что ускоряет запуск и снижает общее потребление памяти;
- позволяет оперативно исправлять уязвимости в сторонних библиотеках. Например если в libfoo обнаружена уязвимость, её мейнтейнеры в дистрибутиве выпустят обновление и после его установки будет достаточно лишь перезапустить наше приложение, чтобы оно подействовало.
- мы привязываем свой бинарник к конкретной версии библиотеки, которая затем должна быть установлена в системе и иметь ту же, либо более новую версию (если имеется обратная совместимость по API/ABI);
- сложность распространения проприетарного ПО. В данном случае потребуется каким-то способом включать все используемые динамические библиотеки в дистрибутив (об этом далее).
Статическая линковка
- всё, от чего зависит бинарник, вшивается непосредственно в него, поэтому он может быть запущен где угодно, на любой системе;
- нет проблем с зависимостями.
- если в используемой библиотеке libfoo будет найдена уязвимость, потребуется полная пересборка и перелинковка всего проекта, а затем распространение обновлённой версии. Часто такое ПО остаётся уязвимым навсегда;
- нет возможности использования разделяемой памяти. Все библиотеки загружаются в адресное пространство процесса, даже если их копии уже присутствуют в памяти;
- огромный размер бинарника;
- проблемы с лицензированием для проприетарного ПО. Ряд лицензий, например GPL, запрещают статическую линковку с собственническим ПО. Лицензия LGPL (под ней распространяется например Qt) статическую линковку допускает, но при этом требует предоставления хотя бы объектных файлов всем покупателям для возможности перелинковки.
Альтернативы RPM/DEB пакетам
Чтобы не собирать пакеты под каждый из дистрибутивов по отдельности, были придуманы так называемые самодостаточные пакеты: Flatpak, AppImage, Snap.
Flatpak
Это наверное самый лучший из самодостаточных пакетов. Поддерживает динамическую линковку с большим количеством библиотек из рантаймов, что решает проблемы с лицензированием, их поддержкой в актуальном состоянии и исправлением в них ошибок, а также уязвимостей. Рантаймы оперативно обновляются мейнтейнерами в пределах версии. Например мы можем слинковаться с Qt версии 5.11 и openssl 1.1.0 и указать их в манифесте, тогда они будут автоматически загружены и установлены у пользователей. Ошибки и уязвимости в них будут исправляться автоматически.
Библиотеки, для которых нет рантаймов, могут быть упакованы внутрь флатпака и подгружаться по мере необходимости.
Flatpak позволяет установить разные версии приложений и библиотек одновременно. К тому же для установки не требуются права администратора.
Также Flatpak поддерживает изоляцию приложения внутри контейнера. В манифесте может быть указано к каким каталогам и ресурсам будет иметь доступ приложение. Всё остальное для него будет запрещено. Права очень гибко настраиваются.
Созданные флатпаки могут загружаться и использоваться на любом дистрибутиве GNU/Linux, поддерживающем их использование.
Репозиторий Flatpak пакетов создаётся достаточно легко и может хоститься на любом ресурсе, позволяющем размещение статических файлов по прямым ссылкам (даже на GitHub pages).
Документацию по Flatpak можно найти на официальном сайте вместе с готовыми примерами.
Нужно ли вообще собирать RPM/DEB пакеты?
Для разработчиков свободного ПО однозначно нет. Когда проект наберёт популярность, мейнтейнеры дистрибутивов опакетят его согласно их официальных гайдлайнов и добавят в основные репозитории. От разработчика здесь требуется лишь не чинить препятствий этому и внедрять исправления, которые могут предложить мейнтейнеры.
Для разработчиков собственнического ПО есть несколько вариантов:
- использовать динамическую линковку и собирать пакеты для каждого популярного дистрибутива в пределах поддерживаемых версий;
- использовать статическую линковку (если нет проблем с лицензиями) и создавать статические бинарники внутри generic RPM/DEB пакетов;
- использовать динамическую линковку и использовать RPATH при сборке бинарника (либо вместо RPATH использовать механизм LD_PRELOAD), а затем упаковывать все необходимые библиотеки внутрь generic RPM/DEB пакета вне стандартной library path, чтобы не вызывать проблем с зависимостями у общесистемных пакетов;
- использовать самодостаточные пакеты, например вышеупомянутый Flatpak.
Для всех разработчиков проприетарного ПО мы настоятельно рекомендуем внедрять Flatpak и по возможности максимально использовать его рантаймы.
Как определить зависимости пакета или двоичного файла
Вы также можете сделать это из Synaptic. Ищите пакет, делайте щелкните правой кнопкой мыши> Свойства> Зависимости.
Чтобы увидеть полное дерево зависимостей (включая зависимости зависимостей пакета), установите apt-rзависит. Чтобы увидеть, как это работает, я рекомендую вам прочитать это другую должность.
DEB свободный
Чтобы просмотреть зависимости пакета DEB, загруженного из Интернета:
dpkg-deb -I mypackage.deb
Где mypackage.deb — имя пакета.
Примечание: чтобы узнать зависимости пакетов DEB, вы также можете получить доступ к базам данных репозиториев вашего любимого дистрибутива. В случае Ubuntu я рекомендую вам получить доступ к База данных пакетов Ubuntu. Для Debian есть База данных пакетов Debian. Здесь перечислены доступные пакеты и их зависимости.
Пакеты RPM
Repositorios
В мире RPM все очень просто. Если пакет находится в репозиториях:
rpm -qR ПАКЕТ
Свободные обороты
Если это свободный пакет RPM:
rpm -qpR ПАКЕТ
Примечание: чтобы узнать зависимости пакетов RPM, вы также можете получить доступ к базам данных репозиториев вашего любимого дистрибутива. В случае Fedora я рекомендую вам получить доступ к База данных пакетов Fedora. Здесь перечислены доступные пакеты и их зависимости.
Двоичные файлы
Чтобы узнать о библиотеках, используемых двоичным файлом в Linux, просто введите:
ldd binary_file
Где двоичный_файл — полное имя (включая путь) рассматриваемого двоичного файла.
В случае, если эти библиотеки, в свою очередь, имеют зависимости, и вы хотите увидеть, что они из себя представляют, я написал:
ldd -v двоичный_файл
Спасибо Росгор за рекомендацию темы!
Содержание статьи соответствует нашим принципам редакционная этика. Чтобы сообщить об ошибке, нажмите здесь.
Полный путь к статье: Из Linux » ФайлДавайте использовать Linux » Как определить зависимости пакета или двоичного файла
4 комментариев, оставьте свой
Оставьте свой комментарий Отменить ответ
ivan80 сказал
тому назад 10 лет
Извините за вопрос, что происходит, так это то, что мне нужен драйвер для принтера xerox workcentre 5020, я уже загрузил его с xerox, но у него есть некоторые зависимости, деталь в том, что эти зависимости находятся в моей системе debian, но уже обновлены, я попытался установить этот пакет, но я запрашиваю больше зависимостей этого пакета, и если я устанавливаю другие, те другие спрашивают меня о других зависимостях, и это становится вечностью зависимостей, которые он может делать, я надеюсь, вы можете мне помочь, заранее спасибо.
Гай Балтар сказал
тому назад 10 лет
Вы пробовали использовать команду apt-get build-dep имя-пакета? Я не знаю, требуется ли это, чтобы это было доступно в репозиториях, но для проверки .
Адриан сказал
тому назад 10 лет
Я прочитал несколько руководств о том, как устанавливать программы путем компиляции, и впервые узнаю об этом совете. Насколько это полезно.
Спасибо, что поделился.
Маркошип сказал
тому назад 10 лет
Я также впервые вижу это для двоичных файлов, хотя обычно при чтении readme они говорят вам. Я собираюсь приступить к его реализации, чтобы посмотреть, что произойдет. Спасибо за информацию!!
Как определить версию Linux?
Линукс — как много в этом слове эмоциональной и смысловой нагрузки. А как много разных дистрибутивов входят в это семейство И частенько требуется понять, какая конкретно версия установлена и этому помогает пакет systemd, который в настоящее время имплементирован во многие дистрибутивы.
Самый простой способ проверить версию Linux это просто использовать hostnamectl команду без каких-либо аргументов. Эта команда возвращает название дистрибутива, версию и кодовое название вместе с конкретной версией ядра.
Довольно распространенной ошибкой является называть все семейство GNU/Linux систем просто Linux-ом. Важный момент в том, что Linux — это только ядро, а GNU — непосредственно сама система в виде набора скомпилированных библиотек и системных инструментов. GNU и Linux должны работать в тандеме для того, чтобы операционная система корректно работала. Так как одно не может существовать без другого, корректнее называть эту связку GNU/Linux или Lignux.
Дополнительные способы определения
Системы управления пакетами в Linux
Если команда выше вам не помогла, следующим шагом будет проверка установленного пакетного менеджера, так как вероятность, что один из трех пакетных менеджеров все-таки установлен крайне высока.
- rpm — пакетный менеджер для систем RedHat
- dpkg — пакетный менеджер для систем Debian
- pacman — пакетный менеджер для систем Arch
Таким образом, если система использует rpm, то скорее всего у вас используется RHEL, CentOS, Fedora и т.д. Если deb, то скорее всего это Ubuntu, Debian, Mint. И соответственно в случае pacman это будет Arch или Manjaro (и им подобные).Для определения пакетного менеджера нужно ввести команду
$ for i in $( echo rpm dpkg pacman ); do which $i; done 2 /dev/null
В случае deb и rpm она вернет следующее: /usr/bin/dpkg и /bin/rpm соответственно.
Проверка версии CentOS/RHEL
Самый простой способ проверки версии CentOS это чтение файла /etc/centos-release с помощью команды cat /etc/centos-release
В свою очередь для RHEL нужно будет прочитать файл /etc/redhat-release
Команду соответственно меняем:
cat /etc/redhat-release
Думаю логика здесь понятна, для Fedora нужно будет поменять команду на fedora-release — проще некуда.
Проверка версии Debian, Mint и Ubuntu
Для Debian — подобных систем нужно прочесть файл /etc/issue:
cat /etc/issue
Проверка версии Arch
Проверять версию Arch не имеет смысла, так как каждый раз при запуске команды pacman -Suy ваша система автоматически обновляется до последней версии.
Проверка системных параметров
Проверка системной архитектуры и версии ядра
Самый простой и популярный способ определения системной архитектуры и версии ядра Linux это использование команды uname с аргументом -a.
То есть команда будет выглядеть следующим образом:
uname - a
В выводе будет указана версия ядра и разрядность архитектуры.
Проверка архитектуры ЦПУ
Самым простым и распространенным способом является команда:
lscpu
Как видно из вывода, вместе с моделью процессора и его частотой также видна его разрядность и еще много различных параметров.