Bug#1118363: libpeas: should move to girepository-2.0 when pygobject does

[Simon McVittie]

Source: libpeas
Severity: important
Tags: upstream
Forwarded: https://gitlab.gnome.org/GNOME/libpeas/-/issues/58
Control: block 1099164 by -1

When pygobject moves from libgirepository-1.0 to libgirepository-2.0 
(the transition from pygobject 3.50.x to 3.52+, #1099164), libpeas needs 
to do the same. This will have to be done in lockstep, with both 
packages uploaded to unstable at the same time and allowed to migrate.

Many of the applications that use libpeas v1 (such as rhythmbox, eog and 
totem) will need to change from libgirepository-1.0 to 
libgirepository-2.0 at the same time. The affected apps are anything 
that calls

    peas_engine_enable_loader (..., "python3");

and also calls any g_irepository function. Confirmed affected:

* gedit (upstream completely disabled Python plugins but that was
  probably an overreaction)
* rhythmbox

Likely affected:

* endeavour
* entangle
* eog
* eom (MATE fork of old eog)
* pluma (MATE fork of old gedit)
* totem

Believed to be unaffected:

* astroid (src:astroidmail) (doesn't directly link libgirepository)
* budgie-*, libbudgie-plugin, libraven (doesn't enable Python plugins)
* diodon (doesn't enable Python plugins)
* geary (doesn't enable Python plugins)
* gitg (doesn't enable Python plugins)
* gnome-shell-pomodoro (doesn't enable Python plugins)
* go-for-it (doesn't enable Python plugins)
* indicator-sensors (doesn't enable Python plugins)
* pragha (doesn't enable Python plugins)

Might need their own changes for the pygobject 3.54 transition but out 
of scope here:

* clapper (uses libpeas2, doesn't directly link libgirepository)
* gnome-builder (uses libpeas2, already uses libgirepository-2.0)
* liferea (uses libpeas2, directly links girepository-1.0)

rhythmbox 3.4.9 has been ported so that it will conditionally compile 
against libgirepository-2.0 if pygobject is version 3.52+, or 
libgirepository-1.0 if pygobject is older. This might be a good template 
for porting other applications.

For the MATE forks of older GNOME apps, we should probably fix the GNOME 
app first, then use its patches as a suggestion for the fork.

    smcv