GNOME package guidelines

Arch package guidelines
32-bit
–
CLR
–
CMake
–
Cross
–
DKMS
–
Eclipse
–
Electron
–
Font
–
Free Pascal
–
GNOME
–
Go
–
Haskell
–
Java
–
KDE
–
Kernel modules
–
Lisp
–
Meson
–
MinGW
–
Node.js
–
Nonfree
–
OCaml
–
Perl
–
PHP
–
Python
–
R
–
Ruby
–
Rust
-
Security
–
Shell
–
VCS
–
Web
–
Wine
The
GNOME
packages on Arch Linux follow a certain schema.
Source URL
GNOME packages normally follow two source URL scheme: a released tarball stored in GNOME's FTP server and a specific commit in the software's Git repository
Using released tarball
When downloading a released tarball, you can get it from
https://download.gnome.org
using the following source array:
source=("https://download.gnome.org/sources/$pkgname/${pkgver%.*}/$pkgname-$pkgver.tar.xz")
where
${pkgver%.*}
returns the
major
.
minor
package version, by removing the suffix of
pkgver
(which is the
micro
package version). E.g., if
pkgver=3.28.0
then
${pkgver%.*}
would return
3.28
.
Using a commit from Git repository
Another common practice is to use as source a specific commit from a GNOME software's source code git repository. It does not classify as a VCS package because Pacman's feature of setting specific commit (see
PKGBUILD(5) § USING VCS SOURCES
) makes PKGBUILD not follow latest development commits neither update the
pkgver
field, using the source from the specified commit hash instead.
See a template below:
PKGBUILD
url="https://gitlab.gnome.org/GNOME/$pkgname"
makedepends=(git)
_commit=
hash_of_a_commit
# tags/
X.Y.Z
source=("git+${url}.git#commit=$_commit")
md5sums=('SKIP')

pkgver() {
  cd $pkgname
  git describe --tags | sed 's/-/+/g'
}
Replace
hash_of_a_commit
with the Git commit hash desired, and replace the
pkgver()
statement to fit the needs of the package you are packaging (see
VCS package guidelines#Git
).
Please notice that since the source is downloaded with
git
, then
git
must be in makedepends and checksums must be set to
'SKIP'
, just like it would happen with any other VCS package. Using
pkgver()
function is highly recommended, so it sets
pkgver
accordingly for the commit hash provided.
Note
GNOME previously used
https://git.gnome.org
, but then migrated to
https://gitlab.gnome.org
[1]
[
dead link
2025-03-15—HTTP 404]
. Old links should automatically redirect to the new gitlab.gnome.org domain, but it might be wise to manually update your source URL.
Meson and GNU build systems
Historically GNOME used
GNU Build System
to build its applications. While there some currently active applications and many inactive applications that still use GNU Build System, most of currently active GNOME applications migrated to Meson Build System.
See
Meson package guidelines
for instructions that fits the packaging needs of most GNOME applications.
Note
Even though GNOME applications are written in different programming languages, you should stick with Meson if that is the build system set for that GNOME application. E.g. Do not use
Rust package guidelines
for GNOME applications written in Rust language because you should use
meson
, not
rustc
or
cargo
to build it.
GSettings schemas
GSettings are the current schemas used by GNOME applications, and can be accessed/read/edited using the GUI tool
dconf
or the CLI tool
gsettings
(provided by
glib2
, which is most likely already installed as dependency). GSettings used to require some attention of the packager, but nowadays no intervention is required.
Some observations:
Applications that use GSettings normally depends on GTK (
gtk3
or later), so GSettings-related dependencies are normally already satisfied.
--disable-schemas-compile
flag in
./configure
used to be required to avoid recompiling GSettings database on
package()
function, but this no longer applies to GNOME applications for some time now, mainly in applications using Meson as build system.
Warning
Even for old, non-Meson GNOME applications, do not call
glib-compile-schemas
in the .install file, as GSettings schema databases are automatically recompiled via
pacman hooks
since
glib2
=2.48.0-2.
GConf schemas
Most GNOME packages migrated from
GConf schemas
to
#GSettings schemas
, but you may cross with an old and obsolete GNOME package to installs these GConf schemas. In these cases,
gconf
AUR
must be added to depends array.
Gconf schemas get installed in the system GConf database, which has to be avoided. Some packages provide a
--disable-schemas-install
flag for
./configure
, which hardly ever works. However,
gconftool-2
has a variable called
GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL
which you can set to tell
gconftool-2
to not update any databases.
When creating packages that install GConf schema files, use
make GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 DESTDIR="${pkgdir}" install
in the PKGBUILD's
package()
function.
Warning
Do not call
gconfpkg
in the .install file, as GConf schemas are automatically installed/removed (while installing/removing the GNOME package) via
pacman hooks
since
gconf
AUR
=3.2.6-4.
ScrollKeeper documentation
GNOME applications do not use
ScrollKeeper
nowadays, but you might come across with a GTK2-based application with that documentation.
Since GNOME 2.20 there is no need to run any command for ScrollKeeper, as
rarian
AUR
reads its OMF files directly.
scrollkeeper-update
is a dummy these days. The only requirement is to include
gnome-doc-utils
AUR
to makedepends array.
You can disable documentation generation using
--disable-scrollkeeper
flag from
./configure
.
GTK icon cache
Many graphical GNOME applications install icons in the system, and those icons are included in an icon cache via the
gtk-update-icon-cache
tool. Every time an icon is added or remove, this tool is used to update the cache.
Note
Do not call
gtk-update-icon-cache
tool in the .install file, as the icon cache is updated via
pacman hooks
since
gtk-update-icon-cache
=3.20.3-2.
The package does
not
need to depend on
gtk-update-icon-cache
as this dependency will be satisfied by packages like
gtk4
etc.
.desktop files
Many packages install Freedesktop.org-compatible
.desktop
files and register MimeType entries in them. These information is stored in a database that has to be updated on every addition or removal. This is the function of the
update-desktop-database
tool.
Note
Do not call
update-desktop-database
in the .install file, as the database is automatically updated via
pacman hooks
since
desktop-file-utils
=0.22-2.
The package does
not
need to depend on
desktop-file-utils
, as this dependency will be satisfied by packages like
gtk4
etc.
AppStream and metainfo files
As many others, most GNOME applications adheres the Freedesktop.org's
AppStream specification
and provide a metainfo file so that a description of the application is shown in application centers, like
gnome-software
or
Flathub
.
GNOME applications usually validate metainfo files if
appstream-util
tool when
meson test
is called in
check()
function.  If
appstream-glib
is not installed, this will simply prevent this particular validation from being executed (i.e. no error will interrupt the build process).
You can identify that
appstream-util
is used by the application using two methods:
The first method is to look in the source code for
appstream-util
by running
grep -R appstream-util
or looking at
data/meson.build
file;
The other method is to read the build process looking for
Program appstream-util found: NO
Add
appstream-glib
to checkdepends array to validate metainfo file.