Project:GNOME/GNOME Bumping Guide

This article aims to provide the reader with sufficient information to add new version of GNOME packages to the ::gentoo repository safely.

GNOME has two major releases per year (in March and September). The upstream release schedule is available here.

Nearly all packages maintained by the GNOME team are hosted on https://gitlab.gnome.org/GNOME/.

The gnome-announce-list, distributor-list, and devel-announce-list mailing lists often contain valuable information for distribution maintainers.

A list of outdated packages (as detected by repology.org) maintained by the GNOME team can be found on packages.gentoo.org.

= Build System diff'ing = It's important to handle upstream packaging changes since the last version when adding a new version to the tree. For example, the new version may have different dependencies, require different versions of dependencies, or have gained or lost configuration options.

To detect these changes, we diff the build system of the last version with that of the new version. For a package called, first copy the ebuild and make the version bump commit:

Run on both old and new ebuilds:

And as root enter the category directory in PORTAGE_TMPDIR.

And diff the build system files between the two versions.

Autotools
From the diff we can see that a newer version of is required.

Meson
From the diff we can see that newer versions of and  are required.

CMake
From the diff we can see that a new version of is required.

= Package Groups = GNOME contains many packages organized into groups that should be bumped together.

Core groups
The core groups are the most critical (i.e., they are the reverse dependencies of the largest number of other GNOME packages) and should be bumped first.

glib

 * 1)  - often not crucial to be done together with the rest
 * 1)  - often not crucial to be done together with the rest
 * 1)  - often not crucial to be done together with the rest
 * 1)  - often not crucial to be done together with the rest
 * 1)  - often not crucial to be done together with the rest
 * 1)  - often not crucial to be done together with the rest
 * 1)  - often not crucial to be done together with the rest

atk

 * - usually not needed to be done together with the above, but each orca release cycle needs at least the same release cycle of the above
 * - usually not needed to be done together with the above, but each orca release cycle needs at least the same release cycle of the above
 * - usually not needed to be done together with the above, but each orca release cycle needs at least the same release cycle of the above
 * - usually not needed to be done together with the above, but each orca release cycle needs at least the same release cycle of the above
 * - usually not needed to be done together with the above, but each orca release cycle needs at least the same release cycle of the above

gtk

 * - split package with its own repository and tags. Doesn't always result in a new tag if nothing changed, but should be checked and updated on each gtk+ bump
 * - split package with its own repository and tags. Doesn't always result in a new tag if nothing changed, but should be checked and updated on each gtk+ bump

vala

 * Update  in
 * Update  in
 * Update  in

TODO

 * dconf, dconf-editor
 * gtk-doc, gtk-doc-am
 * yelp, yelp-xsl, yelp-tools
 * grilo, grilo-plugins
 * eog, eog-plugins
 * cheese, gnome-video-effects

Independent groups
These groups can typically be updated independently of core GNOME.

Patches

 * Both packages have a downstream patch series applied with
 * The patches are from the Fedora and are available in their repos:
 * vte291
 * vte291-cntnr-precmd-preexec-scroll.patch
 * gnome-terminal
 * gnome-terminal-cntr-ntfy-autottl-ts.patch
 * The last patch in the gnome-terminal series ("screen, window: Preserve current toolbox, if any") should be removed. Simply delete it from the .patch file.
 * Compress both patches and upload them to your distfiles directory, since they are too large to go into

gedit


Note that amtk and tepl use a  versioning scheme where unstable releases are denoted with an odd value of. We typically don't care to package those unstable releases.

libxml2
These two (mainly libxslt as the consumer) rely on internal API changes which may be carried out between releases. Be careful when making snapshots, and bump new versions at the same time.