Scope of GNOME MRU

GNOME has a MicroReleaseException for the SRU process. It is documented to be for:

"GNOME (only the core modules and apps, not the entirety of what is hosted on gnome.org) a(approved on 2012-06-22)" 

Unfortunately, as far as the SRU team is aware, there isn’t anywhere which lists what are the core GNOME modules and apps. There have been a number of SRUs straddling the line - is Vala a core GNOME component? Is librsvg? - and it would be helpful to have a definitive list of the components covered by the MRE.

Ideally this list will end up on the Wiki page, but this seems like a sensible place to decide what should be on that list before putting it there.

From the GNOME pov it’s considered a GNOME component whatever is under the GNOME namespace in gitlab, so: https://gitlab.gnome.org/GNOME/.

However, there are indeed some other dependencies that are core dependencies that might be under the FDO umbrella (or others). So for those (a list can be defined as per gnome-build meta dependencies) I guess we should have some clear statement.

The things under the GNOME namespace might be GNOME components, but I’m pretty sure not all those 400+ projects are core GNOME components - the perl GTK2 bindings, for example, don’t seem likely to be core GNOME anymore :wink:

Pulling out the things under the gnome-build meta, it looks like a sensible list would be

- core/baobab.bst
- core/cheese.bst
- core/eog.bst
- core/epiphany.bst
- core/evince.bst
- core/file-roller.bst
- core/gdm.bst
- core/gedit.bst
- core/gnome-backgrounds.bst
- core/gnome-bluetooth.bst
- core/gnome-boxes.bst
- core/gnome-calculator.bst
- core/gnome-calendar.bst
- core/gnome-characters.bst
- core/gnome-clocks.bst
- core/gnome-color-manager.bst
- core/gnome-contacts.bst
- core/gnome-control-center.bst
- core/gnome-desktop.bst
- core/gnome-disk-utility.bst
- core/gnome-font-viewer.bst
- core/gnome-getting-started-docs.bst
- core/gnome-initial-setup.bst
- core/gnome-keyring.bst
- core/gnome-logs.bst
- core/gnome-maps.bst
- core/gnome-menus.bst
- core/gnome-music.bst
- core/gnome-photos.bst
- core/gnome-remote-desktop.bst
- core/gnome-screenshot.bst
- core/gnome-session.bst
- core/gnome-settings-daemon.bst
- core/gnome-shell-extensions.bst
- core/gnome-shell.bst
- core/gnome-software.bst
- core/gnome-system-monitor.bst
- core/gnome-terminal.bst
- core/gnome-tour.bst
- core/gnome-user-docs.bst
- core/gnome-user-share.bst
- core/gnome-weather.bst
- core/mutter.bst
- core/nautilus.bst
- core/orca.bst
- core/rygel.bst
- core/simple-scan.bst
- core/sushi.bst
- core/totem.bst
- sdk/adwaita-icon-theme.bst
- sdk/glib-networking.bst
- sdk/gsettings-desktop-schemas.bst
- sdk/gvfs.bst
- sdk/yelp.bst

Possibly some more out of sdk/ would be sensible, but that also includes a bunch of stuff that should clearly not be covered, like Kerberos and WebKit .

I would add direct dependencies of all of the above that are in the sdk namespace.

That includes components such as gtk, gdk-pixbuf, gjs, clutter, librsvg (see bug #1884326 for a specific discussion on that one)…

Thank you for discussing this here.

In the case of Vala, I have one further question. As far as I understand, a Vala update will provide no immediate benefit in an SRU except in the case that reverse build dependencies are rebuilt. The current SRU microrelease update request does not request that. So is that worth doing at all? Whether or not Vala is a core GNOME component, is an exception to the exception warranted here? For example: what if we said that we only update Vala if there’s specific SRU-qualifying-under-normal-rules user impact in a package that will be fixed by the Vala update and will also be rebuilt as part of the update?

Otherwise my concern is that we risk introducing regressions by updating Vala that will only expose them on further SRUs of other components, that will be much harder to pin down as a result. On the other hand, not updating Vala would not risk this class of regression, and there wouldn’t be any impact to users of Vala-built packages.

There is one use case not covered here: a user might be directly using Vala as published in Ubuntu to build something not in the archive. I propose to accept SRU requests for that use case on an individually assessed case by case basis.

Another relevant datapoint is bug 1892245. As far as I understand, this is a shell extension that was regressed by a microrelease update to gnome-shell due to a deliberate API change in gnome-shell.

1 Like

The SRU team discussed the GNOME MRE today.

@raof is planning to generate a list of packages that are in-scope based on the above discussion.

There are a couple of exceptional cases in relation to GNOME microrelease updates:

  • We don’t consider that Vala will be included as part of the GNOME MRE. Regardless, the Vala situation is special as it’s generally necessary to also rebuild reverse build dependencies for a Vala SRU to have any effect. If Vala microrelease updates are desired, this will need to be justified and requested independently (whether as a one-off or a standing documented case).

  • Microrelease updates to gnome-shell are at risk of regressing packages providing gnome-shell extensions as we discovered in the case of LP: #1892245. Going forward, we’d like to see suitable mitigations for this type of regression before we publish gnome-shell microrelease updates, such as through thorough testing of reverse dependencies.

Further discussion welcome.

1 Like

So, parsing the BuildStream files and keeping only the first level dependencies in core/ and sdk/ gives the following list:

NetworkManager : core-deps
glib : sdk
gobject-introspection : sdk
pygobject : sdk
vala : sdk
accountsservice : core-deps
upower : core-deps
gdm : core
gtk+-3 : sdk
yelp-tools : sdk
gnome-backgrounds : core
gnome-bluetooth : core
libnotify : sdk
gnome-color-manager : core
gnome-desktop : core
adwaita-icon-theme : sdk
appstream-glib : sdk
gnome-control-center : core
cheese : core
gnome-settings-daemon : core
gdk-pixbuf : sdk
gsettings-desktop-schemas : sdk
gnome-getting-started-docs : core
gnome-initial-setup : core
gnome-keyring : core
WebKitGTK : sdk
geoclue : sdk
gcr : sdk
gnome-menus : core
gnome-remote-desktop : core
libsecret : sdk
pipewire : sdk
gnome-session : core
json-glib : sdk
gnome-shell-extensions : core
gnome-shell : core
librsvg : sdk
mutter : core
gjs : sdk
gst-plugins-base : sdk
libsoup : sdk
gnome-tour : core
gnome-user-docs : core
gnome-user-share : core
nautilus : core
gvfs-daemon : core
graphene : sdk
pango : sdk
zenity : sdk
orca : core
at-spi2-atk : sdk
rygel : core
libgee : sdk
tracker : sdk
sushi : core
evince : core
clutter-gst : sdk
clutter-gtk : sdk
clutter : sdk
gtksourceview : sdk
glib-networking : sdk
baobab : core
gst-plugins-bad : sdk
gst-plugins-good : sdk
eog : core
epiphany : core
file-roller : core
gedit : core
gnome-boxes : core
gnome-calculator : core
gnome-calendar : core
gnome-characters : core
gnome-clocks : core
gnome-contacts : core
gnome-disk-utility : core
gnome-font-viewer : core
gnome-logs : core
gnome-maps : core
gnome-music : core
gnome-photos : core
gnome-screenshot : core
gnome-software : core
gnome-system-monitor : core
gnome-terminal : core
gnome-weather : core
simple-scan : core
totem : core
yelp : sdk
yelp-xsl : sdk
dconf-editor : core
devhelp : core
gtk-doc : sdk
gnome-builder : core
sysprof : core

But this is too restrictive - some things which clearly should be under the GNOME MRE, like evolution-data-server are in core-deps.

Including those gets us the list:

NetworkManager : core-deps
ppp : core-deps
glib : sdk
gobject-introspection : sdk
pygobject : sdk
vala : sdk
accountsservice : core-deps
upower : core-deps
gdm : core
dconf : core-deps
libcanberra : core-deps
plymouth : core-deps
gtk+-3 : sdk
yelp-tools : sdk
gnome-backgrounds : core
gnome-bluetooth : core
libnotify : sdk
gnome-color-manager : core
colord-gtk : core-deps
exiv2 : core-deps
vte : core-deps
gnome-desktop : core
adwaita-icon-theme : sdk
appstream-glib : sdk
gnome-control-center : core
ModemManager : core-deps
colord : core-deps
gnome-online-accounts : core-deps
grilo : core-deps
gsound : core-deps
ibus-daemon : core-deps
libgtop : core-deps
libhandy : core-deps
libnma : core-deps
malcontent : core-deps
samba : core-deps
system-config-printer : core-deps
udisks2 : core-deps
cheese : core
gnome-settings-daemon : core
gdk-pixbuf : sdk
gsettings-desktop-schemas : sdk
gnome-getting-started-docs : core
gnome-initial-setup : core
libgweather : core-deps
gnome-keyring : core
WebKitGTK : sdk
geoclue : sdk
gcr : sdk
gnome-menus : core
gnome-remote-desktop : core
LibVNCServer : core-deps
freerdp : core-deps
libsecret : sdk
pipewire : sdk
gnome-session : core
json-glib : sdk
cups-pk-helper : core-deps
geocode-glib : core-deps
gnome-shell-extensions : core
gnome-shell : core
librsvg : sdk
evolution-data-server : core-deps
gnome-autoar : core-deps
startup-notification : core-deps
mutter : core
gjs : sdk
gst-plugins-base : sdk
libsoup : sdk
gnome-tour : core
gnome-user-docs : core
gnome-user-share : core
nautilus : core
gvfs-daemon : core
graphene : sdk
pango : sdk
zenity : sdk
orca : core
pyatspi : core-deps
speech-dispatcher : core-deps
at-spi2-atk : sdk
rygel : core
gssdp : core-deps
gst-editing-services : core-deps
gupnp-av : core-deps
gupnp-dlna : core-deps
gupnp : core-deps
libmediaart : core-deps
libgee : sdk
tracker : sdk
sushi : core
libmusicbrainz : core-deps
evince : core
clutter-gst : sdk
clutter-gtk : sdk
clutter : sdk
gtksourceview : sdk
glib-networking : sdk
baobab : core
gnome-video-effects : core-deps
gst-plugins-bad : sdk
gst-plugins-good : sdk
eog : core
exempi : core-deps
libpeas : core-deps
epiphany : core
libdazzle : core-deps
gspell : core-deps
libgxps : core-deps
file-roller : core
gedit : core
amtk : core-deps
tepl : core-deps
gnome-boxes : core
gtk-vnc : core-deps
libhandy-0 : core-deps
libosinfo : core-deps
libvirt-glib : core-deps
osinfo-db : core-deps
spice-gtk : core-deps
tracker-2 : core-deps
tracker-miners-2 : core-deps
gnome-calculator : core
mpc : core-deps
gnome-calendar : core
gnome-characters : core
gnome-clocks : core
gnome-contacts : core
folks : core-deps
gnome-disk-utility : core
libdvdread : core-deps
gnome-font-viewer : core
gnome-logs : core
gnome-maps : core
libchamplain : core-deps
libgfbgraph-0.2 : core-deps
gnome-music : core
grilo-plugins : core-deps
tracker-miners : core-deps
gnome-photos : core
babl : core-deps
gegl : core-deps
gexiv2 : core-deps
gnome-online-miners : core-deps
libgdata : core-deps
gnome-screenshot : core
gnome-software : core
eos-updater : core-deps
flatpak : core-deps
fwupd : core-deps
liboauth : core-deps
xmlb : core-deps
gnome-system-monitor : core
gtkmm-3 : core-deps
gnome-terminal : core
gnome-weather : core
simple-scan : core
libgusb : core-deps
sane-backends : core-deps
totem : core
totem-pl-parser : core-deps
yelp : sdk
yelp-xsl : sdk
dconf-editor : core
devhelp : core
gtk-doc : sdk
gnome-builder : core
flatpak-builder : core-deps
jsonrpc-glib : core-deps
libgit2-glib : core-deps
template-glib : core-deps
sysprof : core

Which is clearly too much; upower, plymouth, and exiv2 definitely don’t belong in the GNOME MRE.

So I think we need to manually curate this list. As a first, proposal, I’ll put up:

glib : sdk
gobject-introspection : sdk
pygobject : sdk
gdm3 : core
gtk+-3 : sdk
yelp-tools : sdk
gnome-backgrounds : core
gnome-bluetooth : core
libnotify : sdk
gnome-color-manager : core
gnome-desktop : core
adwaita-icon-theme : sdk
gnome-control-center : core
gnome-online-accounts : core-deps
grilo : core-deps
gsound : core-deps
libhandy : core-deps
cheese : core
gnome-settings-daemon : core
gdk-pixbuf : sdk
gsettings-desktop-schemas : sdk
gnome-getting-started-docs : core
gnome-initial-setup : core
libgweather : core-deps
gnome-keyring : core
gcr : sdk
gnome-menus : core
gnome-remote-desktop : core
gnome-session : core
json-glib : sdk
gnome-shell-extensions : core
gnome-shell : core
librsvg : sdk
evolution-data-server : core-deps
gnome-autoar : core-deps
startup-notification : core-deps
mutter : core
gjs : sdk
gst-plugins-base : sdk
gnome-tour : core
gnome-user-docs : core
gnome-user-share : core
nautilus : core
gvfs-daemon : core
rygel : core
tracker : sdk
sushi : core
evince : core
clutter-gst : sdk
clutter-gtk : sdk
clutter : sdk
gtksourceview : sdk
glib-networking : sdk
baobab : core
gnome-video-effects : core-deps
eog : core
epiphany : core
file-roller : core
gedit : core
gnome-boxes : core
gtk-vnc : core-deps
libhandy-0 : core-deps
tracker-2 : core-deps
tracker-miners-2 : core-deps
gnome-calculator : core
gnome-calendar : core
gnome-characters : core
gnome-clocks : core
gnome-contacts : core
folks : core-deps
gnome-disk-utility : core
gnome-font-viewer : core
gnome-logs : core
gnome-maps : core
gnome-music : core
grilo-plugins : core-deps
tracker-miners : core-deps
gnome-photos : core
gnome-online-miners : core-deps
gnome-screenshot : core
gnome-software : core
gnome-system-monitor : core
gtkmm-3 : core-deps
gnome-terminal : core
gnome-weather : core
simple-scan : core
totem : core
totem-pl-parser : core-deps
yelp : sdk
yelp-xsl : sdk
dconf-editor : core
devhelp : core
gtk-doc : sdk
gnome-builder : core

I think some of those are marginal; feel free to suggest ones to remove. Are there any that definitely should be in there that I’ve missed?

So… To make this clear, this is what you’re removing from the full list:

+++ /tmp/post	2020-09-18 12:04:29.831625142 +0200
@@ -1,41 +1,20 @@
-NetworkManager : core-deps
-ppp : core-deps
 glib : sdk
 gobject-introspection : sdk
 pygobject : sdk
-vala : sdk
-accountsservice : core-deps
-upower : core-deps
 gdm3 : core
-dconf : core-deps
-libcanberra : core-deps
-plymouth : core-deps
 gtk+-3 : sdk
 yelp-tools : sdk
 gnome-backgrounds : core
 gnome-bluetooth : core
 libnotify : sdk
 gnome-color-manager : core
-colord-gtk : core-deps
-exiv2 : core-deps
-vte : core-deps
 gnome-desktop : core
 adwaita-icon-theme : sdk
-appstream-glib : sdk
 gnome-control-center : core
-ModemManager : core-deps
-colord : core-deps
 gnome-online-accounts : core-deps
 grilo : core-deps
 gsound : core-deps
-ibus-daemon : core-deps
-libgtop : core-deps
 libhandy : core-deps
-libnma : core-deps
-malcontent : core-deps
-samba : core-deps
-system-config-printer : core-deps
-udisks2 : core-deps
 cheese : core
 gnome-settings-daemon : core
 gdk-pixbuf : sdk
@@ -44,19 +23,11 @@
 gnome-initial-setup : core
 libgweather : core-deps
 gnome-keyring : core
-WebKitGTK : sdk
-geoclue : sdk
 gcr : sdk
 gnome-menus : core
 gnome-remote-desktop : core
-LibVNCServer : core-deps
-freerdp : core-deps
-libsecret : sdk
-pipewire : sdk
 gnome-session : core
 json-glib : sdk
-cups-pk-helper : core-deps
-geocode-glib : core-deps
 gnome-shell-extensions : core
 gnome-shell : core
 librsvg : sdk
@@ -66,30 +37,14 @@
 mutter : core
 gjs : sdk
 gst-plugins-base : sdk
-libsoup : sdk
 gnome-tour : core
 gnome-user-docs : core
 gnome-user-share : core
 nautilus : core
 gvfs-daemon : core
-graphene : sdk
-pango : sdk
-zenity : sdk
-orca : core
-pyatspi : core-deps
-speech-dispatcher : core-deps
-at-spi2-atk : sdk
 rygel : core
-gssdp : core-deps
-gst-editing-services : core-deps
-gupnp-av : core-deps
-gupnp-dlna : core-deps
-gupnp : core-deps
-libmediaart : core-deps
-libgee : sdk
 tracker : sdk
 sushi : core
-libmusicbrainz : core-deps
 evince : core
 clutter-gst : sdk
 clutter-gtk : sdk
@@ -98,65 +53,37 @@
 glib-networking : sdk
 baobab : core
 gnome-video-effects : core-deps
-gst-plugins-bad : sdk
-gst-plugins-good : sdk
 eog : core
-exempi : core-deps
-libpeas : core-deps
 epiphany : core
-libdazzle : core-deps
-gspell : core-deps
-libgxps : core-deps
 file-roller : core
 gedit : core
-amtk : core-deps
-tepl : core-deps
 gnome-boxes : core
 gtk-vnc : core-deps
 libhandy-0 : core-deps
-libosinfo : core-deps
-libvirt-glib : core-deps
-osinfo-db : core-deps
-spice-gtk : core-deps
 tracker-2 : core-deps
 tracker-miners-2 : core-deps
 gnome-calculator : core
-mpc : core-deps
 gnome-calendar : core
 gnome-characters : core
 gnome-clocks : core
 gnome-contacts : core
 folks : core-deps
 gnome-disk-utility : core
-libdvdread : core-deps
 gnome-font-viewer : core
 gnome-logs : core
 gnome-maps : core
-libchamplain : core-deps
-libgfbgraph-0.2 : core-deps
 gnome-music : core
 grilo-plugins : core-deps
 tracker-miners : core-deps
 gnome-photos : core
-babl : core-deps
-gegl : core-deps
-gexiv2 : core-deps
 gnome-online-miners : core-deps
-libgdata : core-deps
 gnome-screenshot : core
 gnome-software : core
-eos-updater : core-deps
-flatpak : core-deps
-fwupd : core-deps
-liboauth : core-deps
-xmlb : core-deps
 gnome-system-monitor : core
 gtkmm-3 : core-deps
 gnome-terminal : core
 gnome-weather : core
 simple-scan : core
-libgusb : core-deps
-sane-backends : core-deps
 totem : core
 totem-pl-parser : core-deps
 yelp : sdk
@@ -165,8 +92,3 @@
 devhelp : core
 gtk-doc : sdk
 gnome-builder : core
-flatpak-builder : core-deps
-jsonrpc-glib : core-deps
-libgit2-glib : core-deps
-template-glib : core-deps
-sysprof : core

That said, there are some that are clearly GNOME projects and on which mostly GNOME core apps depend on (there could be few external cases) and where upstream can be trusted that a new point release works with the whole ecosystem.
Such as:

at-spi2-atk
gspell
gssdp
libcanberra
libdazzle
libgdata
libgee
libgit2-glib
libgtop
libgusb
libpeas
libsoup # Maybe this could be kept away
pyatspi
sysprof
template-glib
vte # There may be gnome-terminal SRUs that require bumping this as well
zenity

That being said, I think we should also define a procedure (that should be quite straight forward) to update the list whenever new upstream GNOME projects have been added (or moved away from the GNOME umbrella).

@3v1n0

Moving this conversation here as this thread is about SRU policy vs. the other one that is only about a specific update.

Assuming that you mean adding a Breaks: package relationship in a gnome-shell microrelease SRU, such that extensions installed from the archive will need to be removed before gnome-shell can be upgraded, I’m not sure that’s safe. If there’s a subsequent security update to gnome-shell, what’s that going to mean for users who are using such shell extensions from the archive? Will apt refuse to install the security update, or will apt force the removal of the extension packages? Either way seems unacceptable to me.

I think an essential requirement for an SRU is that nothing in the archive is knowingly broken as a result of it. We released with these extension packages, and our stability promise we make is that we won’t break them. It then follows that declaring “extensions we can’t support” cannot be used as an excuse to break this promise. However this is probably outside of the scope of the SRU team to decide; I think that if we want to deliberately break compatibility with other packages in the archive in an SRU, then that’s outside the scope of the microrelease update permission given to the SRU team by the Technical Board and so such an exception proposal would have to go back to the Technical Board for their consideration.

An alternative might be not to release such extension packages at all if they’re going to block gnome-shell microrelease updates like this because nobody is committing to do the necessary work. I am generally in favour of removing packages that aren’t being looked after and are also blocking progress. Again that’s not up to the SRU team though; that’d be something to clear with the release team.

Note however that in the case of this particular regression we found that people are using the package and @fcole90 did step up to do the necessary work. Whatever we do, I think we need to figure out how to fit those extension packages into the gnome-shell SRU process so that those who are willing to look after these packages like this can continue to do so without users being regressed first.

I concur, with the caveat that there are sometimes cases where breaking a package in the archive is the least-worst choice.

Certainly each instance would need to be judged individually. The GNOME MRE should not be a blanket permission to break packaged¹ extensions; all packaged extensions should be tested against a new GNOME Shell, and any regressions should be flagged and investigated to see if they can be resolved.

¹: As our policy is that people using 3rd party repositories are on their own, and extensions.gnome.org is a 3rd party repository, it is acceptable (although not ideal) to break unpackaged extensions in a gnome-shell SRU.