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