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
.
- Если аргументы не заданы, просматриваются все файлы в каталоге.
- Если указаны один или несколько аргументов, поиск выполняется по соответствующим именам файлов.