Bug#1017890: Ships autogenerated files that can't be renegerated with the code in Debian main

[Simon McVittie]

On Mon, 22 Aug 2022 at 10:08:10 +0300, Sebastian Dröge wrote:
> While that discussion is about Rust packages that were rejected, the same
> situation also applies to gobject-introspection unfortunately. For more
> details how to solve this in a way that makes ftp-masters happy, please refer
> to them.

Before we go adding a complete copy of GLib to GObject-Introspection,
is there ftp team consensus that the issue described in #1017890 is a
serious bug?

We can add as much extra source and/or extra code generation mechanisms to
these packages as we are required to, but the harder we make it to update
these packages, the longer it will take for someone in the GNOME team
(which is already short of people, like every other team in Debian) to get
these packages updated when they need to be updated.

The doc-comments in gobject-introspection's gir/*.c are analogous
to header files describing an interface, and are human-readable and
editable. They are not really *intended* to be edited, as such, but
editing them is a reasonable way to fix bugs if it becomes necessary.

> Ideally these files would be regenerated during each build with whatever
> version is currently available in Debian, however this might be discouraged by
> upstream as it's not clear anymore then what the exact files are that are
> being used in a specific Debian release compared to the upstream release.

The reason that the inputs used to generate the GIR descriptions
for GLib are shipped by GObject-Introspection rather than GLib is to
resolve a circular dependency. Normally each library generates its own
GObject-Introspection metadata, but GObject-Introspection is a GLib-based
library, so it needs GLib for compilation.

Rather than directly shipping pregenerated GIR XML, GObject-Introspection
ships files containing the doc-comments from GLib. These are a subset
of GLib's source code, created by removing the actual C code (which is
redundant with the information that can be introspected from the actual
libraries and headers) and leaving only the comments.

During GObject-Introspection build, these doc-comments are combined with
runtime introspection of the ABI of GLib's actual libraries to produce
the GIR XML and typelibs.

If the ftp team considers it to be unacceptable to ship a subset of
GLib's source code in GObject-Introspection, then I think there are two
possible routes: either GLib starts building a glib2.0-source.deb similar
to the ones generated by gdb, gcc, etc. so that GObject-Introspection
can consume that package (which will require a trip through NEW), or
GObject-Introspection bundles a copy of the GLib source that corresponds
to the subset distributed by upstream (probably best done as a 3.0 (quilt)
additional tarball).

Bundling a known-compatible copy of the GLib source with
GObject-Introspection would probably be more in line with how this
works upstream. Of course, this would likely involve writing another
unreadable monster of a d/copyright file, but if that's what the ftp
team want to receive, then we can have that.

    smcv