GNOME package guidelines (Русский)
32-bit – CLR – CMake – Cross – DKMS – Eclipse – Electron – Font – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel – Lisp – Meson – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust – Shell – VCS – Web – Wine
Пакеты GNOME в Arch Linux следуют определённой схеме.
URL источников
Пакеты GNOME обычно следуют двум схемам URL источника: выпущенный tarball, хранящийся на FTP-сервере GNOME, и конкретный коммит в Git-репозитории программы.
Использование выпущенного tarball
Скачиваемый tarball можно получить с https://download.gnome.org с помощью такого массива source:
source=("https://download.gnome.org/sources/$pkgname/${pkgver%.*}/$pkgname-$pkgver.tar.xz")
где ${pkgver%.*}
возвращает major.minor версию пакета путём удаления суффикса у pkgver
(который является micro версией пакета). Например, если pkgver=3.28.0, то ${pkgver%.*}
вернёт 3.28.
Использование commit в Git-репозитории
Другая распространённая практика — использование в качестве источника конкретного коммита из git-репозитория GNOME-программы. Это не будет считаться VCS-пакетом, поскольку установка конкретного коммита (смотрите PKGBUILD(5) § USING VCS SOURCES) не приводит к использованию самых новых коммитов и обновлению pkgver
, вместо этого используются исходники именно из указанного коммита.
Шаблон:
PKGBUILD
url="https://gitlab.gnome.org/GNOME/$pkgname" makedepends=(git) _commit=хэш_коммита # tags/X.Y.Z source=("git+${url}.git#commit=$_commit") md5sums=('SKIP') pkgver() { cd $pkgname git describe --tags | sed 's/-/+/g' }
Замените хэш_коммита
на нужый Git-коммит, а pkgver()
замените в соответствии с требованиями упаковываемого пакета (смотрите VCS package guidelines#Git).
Обратите внимание, что, поскольку исходный текст загружается с помощью git, пакет git должен быть указан в makedepends, а в checksums должно быть 'SKIP'
, как и в случае с любым другим VCS-пакетом. Настоятельно рекомендуется использовать функцию pkgver()
, так как она позволяет задать pkgver
, соответствующий указанному коммиту.
Системы сборки Meson и GNU
Исторически GNOME использовал для сборки своих приложений GNU Build System. Несмотря на то, что некоторые активные и неактивные приложения по-прежнему используют его, большинство активных приложений GNOME перешли на Meson Build System.
Инструкции по созданию пакетов с использованием Meson, которые подойдут для большинства приложений GNOME, описаны в статье Meson package guidelines.
Схемы GSettings
GSettings — это текущие схемы, используемые приложениями GNOME, которые можно получить/прочитать/отредактировать с помощью графического инструмента dconf или консольного инструмента gsettings (предоставляется пакетом glib2, который, скорее всего, уже установлен в качестве зависимости). Раньше GSettings требовал некоторого внимания со стороны упаковщика, но сейчас вмешательство не требуется.
Некоторые наблюдения:
- Приложения, использующие GSettings, обычно зависят от GTK (gtk3 или новее), поэтому зависимости, связанные с GSettings, обычно уже удовлетворены.
- Раньше требовался флаг
--disable-schemas-compile
в./configure
, чтобы избежать перекомпиляции базы данных GSettings при выполнении функцииpackage()
, но уже некоторое время это не относится к GNOME-приложениям, в основном к приложениям, использующим Meson в качестве системы сборки.
Схемы GConf
Большинство пакетов GNOME уже используют #Схемы GSettings, но вы можете столкнуться со старым пакетом GNOME, в котором ещё используются схемы GConf. В таком случае нужно добавить gconfAUR в массив depends.
Схемы Gconf устанавливаются в системную базу данных GConf, чего следует избегать. Некоторые пакеты предоставляют флаг --disable-schemas-install
в ./configure
, который почти никогда не работает. Однако в gconftool-2 есть переменная GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL
, которую можно установить, чтобы запретить gconftool-2 обновлять какие-либо базы данных.
При создании пакетов, которые устанавливают файлы схем GConf, используйте
make GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 DESTDIR="${pkgdir}" install
в функции package()
в PKGBUILD.
gconfpkg
в файле .install, так как схемы GConf автоматически устанавливаются/удаляются (при установке/удалении пакета GNOME) с помощью хуков pacman, начиная с версии gconfAUR=3.2.6-4.Документация ScrollKeeper
Приложения GNOME в настоящее время не используют ScrollKeeper, но можно встретить GTK2-приложения с такой документацией.
Начиная с GNOME 2.20, нет необходимости выполнять какую-либо команду для ScrollKeeper, так как rarianAUR читает его OMF-файлы напрямую. Команда scrollkeeper-update ничего не делает. Единственное требование — добавить gnome-doc-utilsAUR в массив makedepends.
Отключить генерацию документации можно с помощью флага --disable-scrollkeeper
в ./configure
.
Кэш значков GTK
Многие графические приложения GNOME устанавливают в систему значки, которые добавляются в кэш с помощью gtk-update-icon-cache. Каждый раз при добавлении или удалении значка он используется для обновления кэша.
- Не вызывайте gtk-update-icon-cache в файле .install, так как кэш значков обновляется с помощью хуков pacman, начиная с версии gtk-update-icon-cache=3.20.3-2.
- Пакет не должен зависеть от gtk-update-icon-cache, так как эта зависимость будет удовлетворяться пакетами типа gtk4 и т. д.
Файлы .desktop
Многие пакеты устанавливают совместимые с Freedesktop.org файлы .desktop
и регистрируют в них записи MimeType. Эта информация хранится в базе данных, которая должна обновляться при каждом добавлении или удалении. Именно эту функцию выполняет update-desktop-database.
- Не вызывайте update-desktop-database в файле .install, так как база данных автоматически обновляется с помощью хуков pacman, начиная с версии desktop-file-utils=0.22-2.
- Пакет не должен зависеть от desktop-file-utils, так как эта зависимость будет удовлетворяться пакетами типа gtk4 и т. д.
Файлы AppStream и metainfo
Большинство GNOME-приложений, как и многие другие, придерживается спецификации AppStream от Freedesktop.org и предоставляет файл metainfo, чтобы описание приложения отображалось в центрах приложений, таких как gnome-software или Flathub.
Приложения GNOME обычно выполняют валидацию файлов metainfo при помощи appstream-util, когда в функции check() вызывается meson test
. Если appstream-glib не установлен, то данная проверка будет просто пропущена (то есть процесс сборки не будет прерван).
Определить, что appstream-util используется приложением, можно двумя способами:
- Первый способ — найти appstream-util в исходном коде, выполнив
grep -R appstream-util
или посмотрев файлdata/meson.build
; - Другой метод — в логах сборки поискать
Program appstream-util found: NO
Добавьте appstream-glib в массив checkdepends, чтобы выполнялась валидация файла metainfo.