Bug#1030223: gobject-introspection mini-policy: separate GIR XML from -dev package to make cross-compilation possible?

[Simon McVittie]

On Wed, 01 Feb 2023 at 10:39:30 +0000, Simon McVittie wrote:
> I think this would require changes to dependent packages if they make
> use of the GIR XML (because build-depending on libflatpak-dev would
> no longer be enough, and it would also be necessary to build-depend on
> gir1.2-flatpak-1.0-dev <!nogir> or similar). If so, this would have to
> be done on a package-by-package basis, with dependent packages changed
> before their dependency. A migration path would be to add
> Provides: gir1.2-flatpak-1.0-dev (= ${binary:Version}) on libflatpak-dev.

The dh_girepository in gobject-introspection (>= 1.78.1-3~) generates a
${gir:Provides} substvar for any package that contains public GIR XML,
partially automating this. For example, libflatpak-dev_1.14.5-1+b1 has
Provides: gir1.2-flatpak-1.0-dev (= 1.14.5-1+b1).

To make this work, a sourceful change is still necessary, to add

    Depends: ${gir:Depends}
    Provides: ${gir:Provides}

to every package that ships GIR XML in the public directories:
/usr/share/gir-1.0/*.gir or /usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0/*.gir.

We also want packages that ship public typelibs
(/usr/lib/${DEB_HOST_MULTIARCH}/girepository-1.0/*.typelib or legacy
/usr/lib/girepository-1.0/*.typelib) to have Depends: ${gir:Depends}.

We also want packages that ship public typelibs that do not match the
package's name to have Provides: ${gir:Provides}. For example,
gir1.2-flatpak-1.0 doesn't need this, because the only typelib it contains
is Flatpak-1.0.gir; but gir1.2-gtk-4.0 *does* need this, because in
addition to Gtk-4.0.typelib, it also contains Gdk-4.0.typelib and others.

The dh_girepository in gobject-introspection (>= 1.78.1-3~) also emits
warnings suggesting that (for example) src:libadwaita-1 should have a
Build-Depends on gir1.2-gtk-4.0-dev, if the Build-Depends isn't already
present and the -dev package already has the necessary Provides. This
will let us get those Build-Depends into place gradually.

It is not fully clear to me how much of this is applicable to private
typelibs or GIR XML, shipped in private locations (for example by mutter,
gnome-shell, muffin, cinnamon and cinnamon-screensaver). There is some
discussion of this on #1057391.

> A side benefit of this would be that we could separate out the GIR XML
> that is provided by src:gobject-introspection (#859013) into one or more
> similar gir1.2-*-dev packages.

I intend to do this next time gobject-introspection goes through NEW, or
as part of the first upload of GLib 2.79.x, whichever is sooner.
(GLib 2.79.x is going to take over responsibility for GLib-2.0.typelib etc.
and GLib-2.0.gir etc. from gobject-introspection.)

On Mon, 17 Apr 2023 at 21:54:23 +0200, Helmut Grohne wrote:
> Let me propose another alternative. Rather than
> have gir1.2-flatpak-1.0-dev be a real binary package, we can provide it
> as a virtual one from libflatpak-dev. The mini-policy would then have to
> be updated such that using the gir files requires depending on a
> gir*-dev package and that a dependency on the regular lib*-dev package
> is insufficient. When enabling the nogir profile, the virtual package is
> removed thus no interface is broken. This variant still breaks
> reproducibility of course.

I would prefer not to be 100% relying on this, because I'd prefer for
build-profiles to be "safe" (no functional changes to package content,
and ideally fully reproducible); but it would be a useful stopgap to
avoid having the NEW queue block forward progress.

> In your second mail, you propose storing pre-built gir files in debian/.

I think I mentioned when talking to Helmut in person that I wasn't
proposing storing pre-built GIR files, only the intermediate "dump" files
that are one of the inputs to generating a GIR file. The workflow goes
like this:

- gcc compiles C headers/source into a shared library

- g-ir-scanner produces GIR XML by:
    - parsing C headers/source
    - generating a temporary file with a list of GObject types learned
      from the C headers/source
    - compiling a "dumper" binary linked to the shared library
    - running the "dumper" binary with the list of GObject types as input
    - parsing the output of the "dumper" binary, which includes things
      that in general can only be known at runtime, like all of a GObject
      type's signals, properties and ancestors

- g-ir-compiler compiles GIR XML into a binary typelib

The GIR XML is a combination of information parsed directly from the C
headers and source (I'd estimate 80%), and information from the output
of the "dumper" binary (I'd estimate 20%).

What I was proposing storing pre-built in debian/ is the input to the
"dumper" binary (list of GObject types), and the corresponding output
(each type's list of signals and so on). This is vaguely analogous
to storing a .symbols file, but not a prebuilt shared or static library.

> I dislike this proposal, because it poses continuous extra effort for
> maintainers. We already struggle with symbols files and shouldn't add
> another variant of them.

I can see that point, and the route I'm currently investigating for
cross-compiling is to, instead, use qemu-user to run the "dumper" binary.

> Given this, would you agree that nogir would make sense right now as a
> non-reproducible profile? It still requires updating all reverse
> dependencies, yeah, but we can do so in parallel. For the migration
> period, we would have missing dependencies in the presence of nogir
> profiles, but these would solely affect users of the nogir profile,
> which would be the ones to report and fix such missing dependencies.

I'm not a fan of non-reproducible profiles, so I think we should aim to
have it become a reproducible profile over time, by splitting out a real
rather than virtual gir1.2-foo-0-dev package where needed; but I think
it could make sense as a non-reproducible profile in the shorter term.

    smcv