Bug#1017890: Ships autogenerated files that can't be renegerated with the code in Debian main
Hello, On Mon 22 Aug 2022 at 10:00AM +01, Simon McVittie wrote: > 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? The basic idea in these cases is that it must be possible to regenerate anything not in its preferred form for modification using the contents of the archive, such that main is self-contained. But whether something is in its preferred form for modification is case-by-case and a matter of judgement, so there's no whole team consensus to be had, really. > 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. Sounds like a subset of the preferred form for modification is still the preferred form for modification, so, without having thought about this as carefully as I would were I reviewing the package in NEW, it sounds like this package is okay. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017890: Ships autogenerated files that can't be renegerated with the code in Debian main
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
Bug#1017890: Ships autogenerated files that can't be renegerated with the code in Debian main
Package: gobject-introspection Version: 1.72.0-1+b1 Severity: serious Tags: upstream Hi, See the discussion on the Debian Rust maintainers list for background: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html 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. gobject-introspection ships gir/glib-2.0.c, gir/gio-2.0.c, gir/gmodule-2.0.c and gir/gobject-2.0.c. These files are autogenerated from a specific version of the GLib source code via the misc/update-glib-annotations.py script. The version that was used in 1.72.0 happens to be GLib 2.72.0 which is not in the archive anymore if you check https://deb.debian.org/debian/pool/main/g/glib2.0/ In this case there are probably no differences if you regenerate the files from glib 2.72.3 but in other releases the situation is a bit more complicated, and various gobject-introspection releases shipped with generated files from some random git snapshot of glib. 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. Alternatively the original source, i.e. glib in the exact version used for the files, could be included in the source package. Note that these files are used to generate the GLib-2.0.gir, Gio-2.0.gir, GModule-2.0.gir and GObject-2.0.gir files that are also shipped in the binary packages. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'unstable-debug'), (100, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gobject-introspection depends on: ii build-essential 12.9 ii libc6 2.34-4 ii libdpkg-perl1.21.9 ii libffi8 3.4.2-4 ii libgirepository-1.0-1 [libgirepository-1.0-1-with-libffi8] 1.72.0-1+b1 ii libglib2.0-02.72.3-1+b1 ii python3 3.10.6-1 ii python3-distutils 3.10.6-1 ii python3-mako1.1.3+ds1-3 ii python3-markdown3.4.1-1 gobject-introspection recommends no packages. gobject-introspection suggests no packages. -- no debconf information
