Professional Documents
Culture Documents
CLR – Cross – Eclipse – Electron – Free Pascal – GNOME – Go – Haskell – Java – KDE –
Kernel – Lisp – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust
– VCS – Web – Wine
Contents
Source URL
Using released tarball
Using a commit from Git repository
GConf schemas
GSettings schemas
Scrollkeeper documentation
.desktop files
.install files
Source URL
This topic contains the most commonly used source URL used by GNOME packages in both official
repositories and AUR. For examples, search for GNOME packages in the official repositories[1]
(https://www.archlinux.org/packages/?q=gnome) and in the AUR[2] (https://aur.archlinux.org
/packages/?K=gnome)
source=("https://download.gnome.org/sources/$pkgname/${pkgver%.*}/$pkgname-$pkgver.tar.xz")
1 de 5 15/4/19 16:06
GNOME package guidelines - ArchWiki https://wiki.archlinux.org/index.php/GNOME_packa...
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.
PKGBUILD
makedepends=(git)
commit=hash_of_a_commit
source=("git+https://gitlab.gnome.org/GNOME/$pkgname.git#commit=$_commit")
md5sums=('SKIP')
pkgver() {
cd $pkgname
git describe --tags | sed 's/-/+/g'
}
Please notice that since the source is downloaded with git, then git
(https://www.archlinux.org/packages/?name=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.
2 de 5 15/4/19 16:06
GNOME package guidelines - ArchWiki https://wiki.archlinux.org/index.php/GNOME_packa...
The build(), check(), and package() functions should look something like:
PKGBUILD
makedepends=(meson)
build() {
meson --prefix /usr --buildtype=plain source build
ninja -C build
}
check() {
ninja -C build check
}
package() {
DESTDIR="$pkgdir" ninja -C build install
}
where
source is the directory containing the extracted source code, e.g. $pkgname or
$pkgname-$pkgver; and
build is the directory that will hold the binary files to be installed. Normally the dirname "build" is
used so you may want to keep it for standardization, but you may rename it to whatever pleases
you.
Note:
Some software do not support invoking meson from outside the source code's root directory. If
that is your case, adapt the above code block by simply adding cd source to the start of the
three functions above, and also changing the above meson command-line to
meson . build .
If the software have no testing rules set (case which the above code block would fail to build
the package), remove/comment the whole check() function.
GConf schemas
3 de 5 15/4/19 16:06
GNOME package guidelines - ArchWiki https://wiki.archlinux.org/index.php/GNOME_packa...
Some GNOME packages install GConf schemas, even though many others already migrated to
GSettings. Those packages should depend on gconf (https://www.archlinux.org/packages
/?name=gconf).
Gconf schemas get installed in the system GConf database, which has to be avoided. Some packages
provide a --disable-schemas-install switch 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.
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
(https://www.archlinux.org/packages/?name=gconf)=3.2.6-4
GSettings schemas
The GConf schemas were migrated to GSettings schemas, so many GNOME applications can be
found using this new schema file. GSettings uses dconf as backend, so all packages that contain
GSettings schemas require dconf (https://www.archlinux.org/packages/?name=dconf) as
dependency. When a new GSettings schema installed on the system, the GSettings database has to
be recompiled, but not when packaging.
Do not call glib-compile-schemas in the .install file, as GSettings schema databases are
automatically recompiled via pacman hooks since glib2 (https://www.archlinux.org
/packages/?name=glib2)=2.48.0-2.
Scrollkeeper documentation
Starting from GNOME 2.20 there is no need to handle scrollkeeper anymore, as rarian
(https://www.archlinux.org/packages/?name=rarian) reads its OMF files directly.
Scrollkeeper-update is a dummy these days. The only required thing now is to makedepend on
gnome-doc-utils (https://www.archlinux.org/packages/?name=gnome-doc-
utils)>=0.11.2.
4 de 5 15/4/19 16:06
GNOME package guidelines - ArchWiki https://wiki.archlinux.org/index.php/GNOME_packa...
Do not call gtk-update-icon-cache in the .install file, as the icon cache is updated via pacman
hooks since gtk-update-icon-cache (https://www.archlinux.org/packages/?name=gtk-
update-icon-cache)=3.20.3-2. These packages should not depend on gtk-update-icon-cache
(https://www.archlinux.org/packages/?name=gtk-update-icon-cache), as any
application which makes use of gtk icon caches will install the package with the hook and do a full,
retroactive cache update.
.desktop files
Many packages install Freedesktop.org compatible .desktop files and register MimeType entries
in them.
.install files
Previously, most of the GNOME packages had a .install file calling commands like
glib-compile-schemas , gtk-update-icon-cache , and update-desktop-database in
order to install/update local cache or databases. This is deprecated since pacman 5.0 implemented
hooks which call those commands automatically when installing the package.
To avoid being called twice, the above mentioned commands should be removed from .install file.
Content is available under GNU Free Documentation License 1.3 or later unless otherwise noted.
5 de 5 15/4/19 16:06