Перейти к основному содержимому
Версия: Canary 🚧

Staplerfile

Stapler использует скрипты сборки, похожие на PKGBUILD's AUR. Ниже описаны требования к содержимому.

Переопределение под дистрибутивы

Использование Stapler в различных дистрибутивах представляет собой некоторые проблемы. Например, некоторые дистрибутивы используют разные названия для своих пакетов. Это решается с помощью переопределений дистрибутива. Любая переменная или функция, используемая в скрипте сборки Stapler, может быть переопределена в зависимости от дистрибутива и архитектуры CPU. Сделать это можно, добавляя наименование дистрибутива и/или архитектуры в конец имени. Например:

deps=('golang')
deps_arch=('go')
deps_opensuse=('go')

Добавление arch и opensuse в конец заставляет Stapler использовать соответствующий массив в зависимости от дистрибутива. Если вы находитесь на Arch Linux, он будет использовать deps_arch. Если на OpenSUSE, он будет использовать deps_opensuse, а если на что-то другое, то будет использовать deps.

Так же можно переопределять в зависимости от версии дистрибутива:

deps=('docker')
deps_altlinux_sisyphus=('docker-engine')
deps_altlinux_p9=('docker-ce')
ВНИМАНИЕ

Так как нет универсального способа получить мажорную версию дистрибутива, так что на каких-то специфичных системах это может работать плохо. Смотри подробнее в DISTRO_RELEASE_ID.

Имена проверяются в следующем порядке:

$name_$architecture_$distro_$release
$name_$distro_$release
$name_$architecture_$distrolike_$release
$name_$distrolike_$release
$name_$architecture_$distro
$name_$distro
$name_$architecture_$distrolike
$name_$distrolike
$name_$architecture
$name

Обнаружение дистрибутива выполняется путем чтения файлов /usr/lib/os-release и /etc/os-release.

Похожие дистрибутивы

Внутри файла os-release есть список "похожих" дистрибутивов. Stapler учитывает это. Например, если скрипт содержит deps_debian, но не deps_ubuntu, сборки Ubuntu будут использовать deps_debian, поскольку Ubuntu основан на Debian.

Предпочтительна наибольшая спецификация, поэтому, если предоставлены как deps_debian, так и deps_ubuntu, Ubuntu и все основанные на нём дистрибутивы будут использовать deps_ubuntu, в то время как Debian и все основанные на нем дистрибутивы, которые не являются основанными на Ubuntu, будут использовать deps_debian.

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

Переменные

к сведению

Переменные и функции, отмеченные (*), являются обязательными.

name*

Переменная name содержит имя пакета, описанного в скрипте (должно совпадать с наименованием каталога в репозитории который содержит скрипт сборки пакета Stapler).

version*

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

Сравнение версий выполняется с использованием алгоритма rpmvercmp.

release*

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

epoch

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

desc

Поле desc содержит описание пакета. Оно не должно содержать переносов строк.

homepage

Поле homepage содержит URL-адрес сайта проекта, упакованного данным скриптом.

maintainer

Поле maintainer содержит имя и адрес электронной почты человека, поддерживающего пакет. Пример:

Ivan Ivanov <iivanov@example.ru>

Хотя Stapler не требует установки этого поля, Debian отказался от неустановленных полей maintainer и может запретить их использование в пакетах .deb в будущем.

architectures

Массив architectures содержит все архитектуры, которые поддерживает данный пакет. Они соответствуют списку GOARCH языка Go, за исключением некоторых отличий.

Архитектура all будет переведена на правильный термин для формата упаковки. Например, он будет изменен на noarch, если строится .rpm, или any, если строится пакет Arch.

Поскольку существует несколько вариантов архитектуры arm, должны использоваться следующие значения:

arm5: armv5
arm6: armv6
arm7: armv7

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

STPLR_ARM_VARIANT=arm5 stplr install ...

license

Массив license содержит лицензии, используемые этим пакетом. Для стандартизации названий лицензий значения должны быть идентификаторами SPDX такими как Apache-2.0, MIT и GPL-3.0-only. Если проект использует лицензию, которая не стандартизирована в SPDX, используйте значение Custom. Если проект имеет несколько нестандартных лицензий, включите Custom столько раз, сколько есть нестандартных лицензий.

provides

Массив provides указывает, какие функции предоставляет пакет. Например, если два пакета собирают ffmpeg с разными флагами сборки, оба должны иметь ffmpeg в массиве provides.

conflicts

Массив conflicts содержит имена пакетов, которые конфликтуют с пакетом, собранным данным скриптом. Если два различных пакета содержат исполняемый файл для ffmpeg, их нельзя установить одновременно, поэтому они конфликтуют. Массив provides также будет проверяться, поэтому этот массив обычно содержит те же значения, что и provides.

deps

Массив deps содержит зависимости для пакета. Репозитории Stapler будут проверены первыми, и если пакеты существуют там, они будут собраны и установлены. В противном случае они будут установлены из системных репозиториев вашим менеджером пакетов.

build_deps

Массив build_deps содержит зависимости, которые необходимы для сборки пакета. Они будут установлены перед началом сборки. Аналогично массиву deps, сначала будут проверены репозитории Stapler.

opt_deps

Массив opt_deps содержит необязательные зависимости для пакета. Описание можно добавить после ": ", но это не обязательно.

opt_deps_arch=(
'git: Управление репозиториями git'
'aria2: Менеджер загрузок'
)

replaces

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

sources

Массив sources содержит URL-адреса, которые загружаются в $srcdir перед началом сборки.

Если предоставленный URL является архивом или сжатым файлом, он будет извлечен. Чтобы отключить это, добавьте параметр ~archive=false. Пример: Извлеченный:

https://example.com/archive.tar.gz

Не извлеченный:

https://example.com/archive.tar.gz?~archive=false

Если схема URL начинается с git+, источник будет загружен как git-репозиторий. Режим загрузки git поддерживает несколько параметров:

~rev: Укажите, какую ревизию репозитория нужно проверить. ~depth: Укажите, какая глубина должна использоваться при клонировании репозитория. Должна быть целым числом. ~name: Укажите имя директории, в которую должен быть клонирован git-репозиторий. ~recursive: Если установлено в true, вложенные модули будут клонироваться рекурсивно. По умолчанию false. #tag=v${version}: Укажите тег, версия которого необходима из репозитория.

Примеры:

git+https://git.example.com/foo/itd?~rev=resource-loading&~depth=1

git+https:/altlinux.space/stapler/stplr?~rev=v0.0.1&~recursive=true

checksums

Массив checksums должен быть такой же длины, как и массив sources. Он содержит контрольные суммы для исходных файлов. Файлы проверяются на соответствие контрольным суммам, и сборка завершается неудачей, если они не совпадают.

По умолчанию ожидаются контрольные суммы в формате sha256. Чтобы изменить алгоритм, добавьте его перед хешем с двоеточием между ними. Например, md5:bc0c6f5dcd06bddbca9a0163e4c9f2e1. В настоящее время поддерживаются следующие алгоритмы: sha256, sha224, sha512, sha384, sha1 и md5.

Чтобы пропустить проверку для определенного источника, установите соответствующую контрольную сумму в SKIP.

backup

Массив backup содержит файлы, которые должны быть сохранены при обновлении и удалении. Точное поведение этого зависит от вашего менеджера пакетов. Все файлы в этом массиве должны быть полными путями назначения. Например, если существует конфигурационный файл под названием config в /etc, который вы хотите сохранить, вы должны установить его так:

backup=('/etc/config')

scripts

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

scripts=(
['preinstall']='preinstall.sh'
['postinstall']='postinstall.sh'
['preremove']='preremove.sh'
['postremove']='postremove.sh'
['preupgrade']='preupgrade.sh'
['postupgrade']='postupgrade.sh'
['pretrans']='pretrans.sh'
['posttrans']='posttrans.sh'
)

Примечание: Для данного синтаксиса кавычки обязательны из-за ограничений парсера bash.

Скрипты preupgrade и postupgrade доступны только в пакетах .apk и Arch Linux.

Скрипты pretrans и posttrans доступны только в пакетах .rpm.

Остальные скрипты доступны во всех пакетах.

auto_reqprov_method

Тип механизма auto_req/auto_prov. Возможные значения: dirty, rpm. По умолчанию - rpm.

auto_reqprov_method="rpm"
auto_reqprov_method="dirty"

Метод rpm использует системные механизмы RPM-дистрибутива для автоматического определения зависимостей и предоставляемых библиотек на основе содержимого пакета. Он обеспечивает более точный и привычный результат, совместимый с RPM-сборкой, но требует наличия системных утилит и корректной среды. Для корректной работы метод rpm часто явного указания в build_deps *-devel пакетов или пакетов с нужными lib*.so-зависимостями, поскольку определение зависимостей может опираться как на заголовочные файлы и .pc-метаданные, так и на наличие самих библиотек в системе.

Метод dirty ищет зависимости и предоставляемые библиотеки внутри пакета, просматривая ELF-файлы (исполняемые файлы и библиотеки) напрямую. Он грубо определяет, какие библиотеки нужны и какие предоставляет сам пакет, без использования внешних инструментов. Этот способ работает автономно и подходит для простого поиска зависимостей при сборке.

auto_req

Автоматическое определение зависимостей пакета.

auto_req=1

auto_req_skiplist

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

# auto_reqprov_method=rpm
auto_req_skiplist_fedora=(
"^/usr/bin/.*-req$"
"^/opt/myapp/.*\.py$"
)
auto_req_skiplist_altlinux=(
"/usr/bin/*-req"
"/opt/myapp/**/*.py"
)
# auto_reqprov_method=dirty
auto_req_skiplist=(
"/usr/bin/*-req"
"/opt/myapp/**/*.py"
)

auto_req_filter

к сведению

На данный момент работает только для метода auto_reqprov_method="dirty"

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

auto_req_skiplist=(
"libcap\.so\.2"
)

auto_prov

Автоматическое определение предоставляемых файлов/бинарников (provides) пакета.

auto_prov=1

auto_prov_skiplist

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

auto_prov_skiplist_fedora=(
"^/usr/bin/.*-req$"
"^/opt/myapp/.*\.py$"
)
auto_prov_skiplist_altlinux=(
"/usr/bin/*-req"
"/opt/myapp/**/*.py"
)

disable_network

Отключает доступ к интернету

disable_network=1

Источники (sources) будут загружены до отключения сети. В процессе сборки сетевые подключения недоступны, что исключает обращение к внешним ресурсам.

firejailed

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

firejailed=1

Для корректной работы необходимо определить firejail_profiles.

firejail_profiles

Ассоциативный массив, сопоставляющий исполняемые файлы с соответствующими профилями Firejail.

firejail_profiles=(
['default']='firejail.profile'
['/usr/bin/app']='custom-firejail.profile'
)

nonfree

Помечает пакет как несвободный (non-free), требующий принятия лицензионного соглашения пользователем.

nonfree=1

Если задано, при сборке/установке пакета (в интерактивном режиме) пользователю будет показано предупреждение и текст соглашения. В случае отказа (нажатие n/q/Esc) процесс прерывается.

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

nonfree_msg

Строка с произвольным текстом лицензионного соглашения. Будет показана пользователю в интерфейсе при включённом nonfree=1.

nonfree_msg="This software contains proprietary software from Google. Redistribution and modification may be restricted."

Если задан и nonfree_msgfile, будет проигнорирован — приоритет у nonfree_msgfile.

nonfree_msgfile

Путь к файлу с текстом лицензионного соглашения.

nonfree_msgfile="LICENSE.txt"

Если задан, его содержимое будет показано пользователю при включённом nonfree=1. Имеет приоритет над nonfree_msg.

nonfree_url

Ссылка на полное лицензионное соглашение (или репозиторий проекта), будет отображена внизу экрана при подтверждении лицензии.

nonfree_url="https://www.google.com/intl/ru/chrome/terms/"

Допускается только одна ссылка.

Функции

В этом разделе описаны функции, определяемые пользователем, которые могут быть добавлены в скрипты сборки. Любые функции, отмеченные (*), являются обязательными.

Все функции выполняются в директории $srcdir.

prepare()

Функция prepare() предназначена для подготовки исходных файлов к сборке и упаковке. Это функция, в которой должны применяться патчи, например, с помощью команды patch, и где должны выполняться инструменты, такие как go generate.

build()

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

build() {
make
}

package()*

Функция package() — это место, куда помещаются собранные файлы в директорию, которая будет использоваться Stapler для сборки пакета.

Все файлы, которые должны быть установлены в файловой системе, должны быть помещены в директорию $pkgdir в данной функции. Например, если у вас есть бинарный файл под названием bin, который должен быть помещен в /usr/bin, и конфигурационный файл под названием bin.cfg, который должен быть помещен в /etc, то функция package() может выглядеть так:

package() {
install -Dm755 bin ${pkgdir}/usr/bin/bin
install -Dm644 bin.cfg ${pkgdir}/etc/bin.cfg
}

files()

Перечисляет все файлы входящие в пакет (требуется для корректного удаления в RPM).

Пример использования:

files() {
files-find-lang yandex-disk
files-find-doc yandex-disk
files-find-binary yandex-disk
files-find-license yandex-disk

files-find \
"/etc/bash_completion.d/yandex-disk-completion.bash" \
"/usr/share/man/**/man1/*"
}
$ rpm -qpl ./*.rpm
/etc/bash_completion.d/yandex-disk-completion.bash
/usr/bin/yandex-disk
/usr/share/doc/yandex-disk
/usr/share/doc/yandex-disk/changelog.gz
/usr/share/doc/yandex-disk/copyright
/usr/share/licenses/yandex-disk
/usr/share/licenses/yandex-disk/LICENSE
/usr/share/locale/ru/LC_MESSAGES/yandex-disk.mo
/usr/share/locale/tr/LC_MESSAGES/yandex-disk.mo
/usr/share/locale/uk/LC_MESSAGES/yandex-disk.mo
/usr/share/man/man1/yandex-disk.1.gz
/usr/share/man/ru/man1/yandex-disk.1.gz
/usr/share/man/tr/man1/yandex-disk.1.gz
/usr/share/man/uk/man1/yandex-disk.1.gz

Переменные окружения

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

DISTRO_NAME

Переменная DISTRO_NAME — это имя дистрибутива, определенное в его файле os-release.

Например, в образе Docker Fedora 36 оно установлено в Fedora Linux.

DISTRO_PRETTY_NAME

Переменная DISTRO_PRETTY_NAME — это "красивое" имя дистрибутива, определенное в его файле os-release.

Например, в образе Docker Fedora 36 оно установлено в Fedora Linux 36 (Container Image).

DISTRO_ID

Переменная DISTRO_ID — это идентификатор дистрибутива, определенный в его файле os-release. Это то же самое, что и то, что Stapler использует для переопределений.

Например, в образе Docker Fedora 36 оно установлено в fedora.

DISTRO_ID_LIKE

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

Например, в образе Docker OpenSUSE Tumbleweed она установлена в opensuse suse, а в образе Docker CentOS 8 — в rhel fedora.

DISTRO_VERSION_ID

Переменная DISTRO_VERSION_ID — это идентификатор версии дистрибутива, определенный в его файле os-release.

Например, в образе Docker Fedora 36 она установлена в 36, а в образе Docker Debian Bullseye — в 11.

DISTRO_RELEASE_ID

Переменная DISTRO_RELEASE_ID — это идентификатор, уникально определяющий версию или ветку пакетной базы дистрибутива, основанный на данных из файла os-release. Значение формируется с учётом специфики дистрибутива. Например:

  • для дистрибутивов, подобных RHEL или Fedora, DISTRO_RELEASE_ID соответствует мажорной версии пакетной базы (например, 36 для Fedora 36 или 8 для RHEL 8).
  • для дистрибутивов, подобных Ubuntu или Debian, DISTRO_RELEASE_ID отражает кодовое имя ветки репозитория (например, bullseye для Debian 11 или focal для Ubuntu 20.04).
  • для ALT Linux берётся из ALT_BRANCH_ID (например, p10).

Если специальная обработка не предусмотрена, DISTRO_RELEASE_ID может быть выведено из VERSION_ID, используя первую часть до точки (например, 11 для 11.4). Все неалфавитно-цифровые символы заменяются на подчеркивание (_) для унификации.

ARCH

Переменная ARCH — это архитектура машины, на которой выполняется скрипт. Она использует ту же схему именования, что и значения в массиве architectures.

NCPU

Переменная NCPU — это количество доступных на машине процессоров, на которой выполняется скрипт. Например, на четырёхъядерной машине с гипертредингом оно будет установлено в 8.

Вспомогательные команды

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

install-binary

install-binary принимает 1-2 аргумента. Первый аргумент — это бинарный файл, который вы хотите установить. Второй — это имя файла, которое должно быть использовано.

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

Примеры:

install-binary ./itd
install-binary ./itd itd-2

install-systemd

install-systemd устанавливает обычные системные службы systemd (см. install-systemd-user для пользовательских служб).

Он принимает 1-2 аргумента. Первый аргумент — это служба, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.

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

Примеры:

install-systemd ./syncthing@.service

install-systemd-user

install-systemd-user устанавливает пользовательские службы systemd (службы, предназначенные для запуска с флагом --user).

Он принимает 1-2 аргумента. Первый аргумент — это служба, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.

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

Примеры:

install-systemd-user ./itd.service infinitime-daemon.service

install-config

install-config устанавливает конфигурационные файлы в директорию /etc.

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

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

Примеры:

install-config ./itd.toml
install-config ./itd.example.toml itd.toml

install-license

install-license устанавливает файл лицензии.

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

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

Примеры:

install-license ./LICENSE itd/LICENSE

install-completion

install-completion устанавливает файлы для автозавершения для командной строки.

В настоящее время поддерживаются bash, zsh и fish.

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

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

Примеры:

./k9s completion fish | install-completion fish k9s
install-completion bash k9s <./k9s/completions/k9s.bash

install-manual

install-manual устанавливает страницы man. Она принимает один аргумент, который является путем к странице man.

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

Примеры:

install-manual ./man/strelaysrv.1
install-manual ./mdoc.7

install-desktop

install-desktop устанавливает desktop-файлы для приложений. Он принимает 1-2 аргумента. Первый аргумент — это конфигурация, которую вы хотите установить. Второй — это имя файла, которое должно быть использовано.

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

Примеры:

install-desktop ./${name}/share/admc.desktop
install-desktop ./${name}/share/admc.desktop admc-app.desktop

install-pixmap

install-pixmap устанавливает иконку в каталог /usr/share/pixmaps внутри пакета.

Она принимает 1–2 аргумента:

  • Первый аргумент — путь к входному файлу иконки.
  • Второй (необязательный) аргумент — имя файла, под которым иконка будет установлена.

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

Примеры:

install-pixmap ./icon.png
install-pixmap ./icon.png mytool-icon.png

В первом случае файл будет установлен как /usr/share/pixmaps/icon.png, во втором — как /usr/share/pixmaps/mytool-icon.png.

install-library

install-library устанавливает общие и статические библиотеки в правильное место.

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

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

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

Примеры:

install-library ./${name}/build/libadldap.so

git-version

git-version возвращает номер версии на основе git-ревизии репозитория.

Если аргумент предоставлен, он будет использован как путь к репозиторию. В противном случае будет использован текущий каталог.

Номер версии будет содержать количество ревизий, точку и короткий хеш текущей ревизии. Например: 118.e4b8348.

Конвенция AUR включает букву r в начале номера версии. Это опускается, так как некоторые дистрибутивы ожидают, что номер версии начнется с цифры.

Примеры:

git-version
git-version "$srcdir/stplr"

files-find

files-find ищет файлы, соответствующие заданным glob-шаблонам, начиная с корня пакета ($pkgdir).

Она принимает один или несколько аргументов — glob-шаблонов.

files-find \
"/opt/google/**/*" \
"/usr/share/appdata/*" \
"/usr/share/applications/*" \
"/usr/share/gnome-control-center/default-apps/*" \
"/usr/share/icons/hicolor/*/apps/*" \
"/usr/share/licenses/**/*" \
"/usr/share/man/man1/*" \
"/usr/bin/*"

files-find-lang

files-find-lang ищет локализационные .mo-файлы, установленные в /usr/share/locale внутри пакета.

Она принимает необязательный аргумент — базовое имя файла (без расширения), по которому фильтруется результат (например, myapp будет соответствовать myapp.mo).

Если аргумент не указан, выбираются все .mo-файлы.

Примеры:

files-find-lang
files-find-lang myapp

В первом случае будут найдены все .mo-файлы в /usr/share/locale. Во втором — только myapp.mo.

files-find-doc

files-find-doc ищет документацию, установленную в /usr/share/doc внутри пакета.

Она принимает необязательный аргумент — шаблон имени каталога (glob), например mytool*. По умолчанию обрабатываются все директории внутри /usr/share/doc.

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

Примеры:

files-find-doc
files-find-doc mytool
files-find-doc mytool-*

В первом случае будут найдены все файлы из /usr/share/doc/**. Во втором и третьем — только те, что находятся в каталогах с именем, соответствующим шаблону (mytool или mytool-*).

files-find-binary

files-find-binary ищет исполняемые файлы в каталоге /usr/bin.

  • Если аргументы не заданы, просматриваются все файлы в каталоге.
  • Если указаны один или несколько аргументов, поиск выполняется по соответствующим именам файлов.

files-find-systemd-user

files-find-systemd-user ищет unit-файлы systemd пользователя в каталоге /usr/lib/systemd/user.

  • Если аргументы не заданы, просматриваются все файлы в каталоге.
  • Если указаны один или несколько аргументов, поиск выполняется по соответствующим именам unit-файлов.

files-find-systemd

files-find-systemd ищет системные unit-файлы systemd в каталоге /usr/lib/systemd/system.

  • Если аргументы не заданы, просматриваются все файлы в каталоге.
  • Если указаны один или несколько аргументов, поиск выполняется по соответствующим именам unit-файлов.

files-find-config

files-find-config ищет конфигурационные файлы в каталоге /etc.

  • Если аргументы не заданы, просматриваются все файлы в каталоге.
  • Если указаны один или несколько аргументов, поиск выполняется по соответствующим именам файлов.

files-find-license

files-find-license ищет лицензионные файлы в каталоге /usr/share/licenses.

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

files-find-desktop

files-find-desktop ищет .desktop-файлы в каталоге /usr/share/applications.

  • Если аргументы не заданы, просматриваются все файлы в каталоге.
  • Если указаны один или несколько аргументов, поиск выполняется по соответствующим именам файлов.

files-find-pixmap

files-find-pixmap ищет иконки в каталоге /usr/share/pixmaps.

  • Если аргументы не заданы, просматриваются все файлы в каталоге.
  • Если указаны один или несколько аргументов, поиск выполняется по соответствующим именам файлов.