Speaker
Description
Sugar has been in tree since April 2006. Its last toolkit transition, GTK2 to GTK3, ran from October 2011 to the 0.98 release in November 2012. The current one, GTK3 to GTK4 and X11 to Wayland, is in its second year across twelve repositories. I ported the toolkit and presented that work at GNOME Asia Summit 2025; this year I mentor the two contributors porting the sugar shell and the activities set we call Fructose. The stack is deliberately half-migrated and will stay that way for some time.
The code side of a toolkit migration is documented. The build side is not, and it has cost this project more time than the porting.
Nothing detects that a set of GObject Introspection typelibs disagree about a major version. The shell requires eleven GI namespaces. One is the project's own C helper library, whose installed typelib was built against GTK3, loaded into a process that already holds GTK4. The process dies at import. In C this is a link error. In GI there is no build-time or package-time gate, and no way to ask whether a set of typelibs can share one process, even though the information is in the typelibs. We fixed it by bumping our own namespace from SugarExt-1.0 to SugarExt-2.0 so the two cannot be confused, which works and is what I would tell the next project to do. Nothing identified it as the problem. It took the first five weeks of a contributor's summer to find. It will recur for any GI-based project that migrates a toolkit while carrying its own introspected library.
The versions you have decides what you can test, and nobody has written that down. The shell puts a Wayland compositor inside a widget (Casilda), so activities run as Wayland clients inside the shell. Casilda 1.2.1 is the last version that builds against wlroots 0.19. Version 1.2.2 moved to wlroots 0.20, and 1.2.4 raised the GTK requirement to 4.22.2. Our pinned nixpkgs gives us GTK 4.20.3 and wlroots 0.19.2. So a pin two layers away from our own code decides which Casilda we can have, and that decides what a reviewer can run. A contributor on Debian and a reviewer on Nix could not reproduce each other's bugs.
Even then, a git checkout is not something you can build. Some files only exist in a release tarball: a config module built from a template, and compiled GSettings schemas. You have to make those by hand. One runtime dependency is packaged by no distribution. And the tree carries three build systems at once: autotools from 2006, Meson in the C library, and a pyproject in the new toolkit.
Questions I would like to put to the room:
- Should typelib agreement be a build-time or package-time check? A typelib carries its dependency list version-qualified, readable without loading it. Debian lintian already requires that a package declare a strictly versioned dependency on the typelibs it needs. What I could not find is anything that takes a set of typelibs and answers whether they can share one process. Does that exist, or is there a reason not to build it?
- How should a build system or a distribution represent a stack that is deliberately half-migrated, where the right answer to "which version" differs per repository and changes weekly?
- What do you hand a new contributor so they can build a multi-repository stack mid-migration?
- Is there anything for coordinating the patches distributions each end up carrying during an ecosystem-wide toolkit transition?
Reference material:
- Shell migration, 188 files: https://github.com/sugarlabs/sugar/pull/1106
- C helper library, autotools to Meson and GDK4 event porting: https://github.com/sugarlabs/sugar-ext/pull/6
- Toolkit migration talk, GNOME Asia Summit 2025: https://www.youtube.com/live/WZ63lQ-DsOA?t=14725
- GTK4 migration guide: https://docs.gtk.org/gtk4/migrating-3to4.html