On Sat, 17 Aug 2024 at 22:28:40 +0200, Helmut Grohne wrote: > Hi Simon, > > I fear we need to have another conversation about glib2.0 and > bootstrapping.
I'm sorry, I am not able to provide a service level agreement for being held responsible for being the single point of failure for glib2.0 and/or architecture bootstrapping. The message I'm receiving from having multiple important-severity bugs filed against GLib and specifically invoking my name is something along the lines of: "I'm holding the GLib maintainers responsible for fixing this, I'm additionally holding Simon personally responsible for fixing this, and if it isn't fixed to my satisfaction, the next step will be to escalate it to RC so that it has to be your highest priority, under the threat of it being your fault that every mainstream GUI was removed from Debian". I hope this was not what you meant, but it's what I'm hearing, and feeling like I'm being put under that pressure by a volunteer project is not pleasant. > debian/rules:30: *** Cross-compiling gobject-introspection requires host > endianness = build endianness. Stop. Now that we're running the host g-ir-compiler under qemu, instead of running the build architecture g-ir-compiler with altered search paths (which turned out to be wrong anyway), it might be possible to remove this check. Perhaps you could try it, diff the resulting typelibs vs. natively-built ones and see whether that's the case? s390x on amd64 (opposite endianness but same word size) or i386 on s390x (opposite endianness *and* different word size) might be good cases to try. Failing that, am I right to think that being able to bootstrap or cross-compile an architecture when we already have at least one other architecture of the same endianness is a lesser evil than being unable to bootstrap or cross-compile any architecture at all? There is a limit to how much I can accommodate unconditional demands: we're constrained by how GLib has been designed and how it works, and if other low-level packages have chosen to depend on it, then that's just something that we will have to live with. > Do you see any way of splitting libglib2.0-0t64 and libglib2.0-dev into > more granular packages with the goal of being able to cross build > something smaller for another endianess? In order to be useful, it would > have to be split in such a way that we can actually reduce a build > dependency of relevant packages to the smaller thing. One obvious choice would be to split up libglib2.0-dev and libglib2.0-dev-bin so that the (former) GObject-Introspection toolchain is separated from the rest of GLib. The qemu dependency goes with the formerly-GObject-Introspection parts, but I didn't want to take another trip through NEW (with the associated risk of having the ftp team reject it, or hold half of Debian hostage until we make debian/copyright sufficiently verbose) to add a second -dev and a second -dev-bin without knowing that it would actually solve anything for your use-case. The GObject-Introspection-derived parts are, in libglib2.0-dev: - /usr/lib/${multiarch}/glib-2.0/deb-can-run - /usr/lib/${multiarch}/glib-2.0/gi-* - /usr/bin/${gnu_type}-gi-compile-repository - /usr/bin/${gnu_type}-gi-decompile-typelib - /usr/bin/${gnu_type}-gi-inspect-typelib and in libglib2.0-dev-bin: - /usr/bin/gi-compile-repository - /usr/bin/gi-decompile-typelib - /usr/bin/gi-inspect-typelib plus the corresponding man pages. Another obvious choice would be to split up both libglib2.0-0t64 and libglib2.0-dev along shared library lines, although I don't know how much this would actually help. In order from bottom to top of the stack, I think it breaks down like this: - GLib core + GThread (probably too intermingled to separate, and probably not useful to separate anyway): - /usr/include/glib-2.0/glib/ - /usr/include/glib-2.0/glib.h - /usr/include/glib-2.0/glib-unix.h - /usr/lib/${multiarch}/glib-2.0/include - /usr/lib/${multiarch}/libglib-2.0.* - /usr/lib/${multiarch}/libgthread-2.0.* - /usr/lib/${multiarch}/pkgconfig/glib-2.0.pc - /usr/lib/${multiarch}/pkgconfig/gthread-2.0.pc - /usr/share/glib-2.0/gdb/glib_gdb.py - /usr/share/gdb/auto-load/usr/lib/${multiarch}/libglib-*-gdb.py - /usr/share/glib-2.0/valgrind/glib.supp - (dev-bin) /usr/bin/glib-gettextize (I think) - (dev-bin, deprecated) /usr/bin/gtester - (dev-bin, deprecated) /usr/bin/gtester-report - (dev-bin) /usr/share/aclocal/glib-2.0.m4 - (dev-bin) /usr/share/aclocal/glib-gettext.m4 - (dev-bin) /usr/share/glib-2.0/gettext (I think) - GModule (probably no real benefit to separating this from GLib either): - /usr/include/glib-2.0/gmodule/ - /usr/include/glib-2.0/gmodule.h - /usr/lib/${multiarch}/libgmodule-2.0.* - /usr/lib/${multiarch}/pkgconfig/gmodule*.pc - GObject: - /usr/include/glib-2.0/gobject/ - /usr/include/glib-2.0/glib-object.h - /usr/lib/${multiarch}/libgobject-2.0.* - /usr/lib/${multiarch}/pkgconfig/gobject-2.0.pc - /usr/share/glib-2.0/gdb/gobject_gdb.py - /usr/share/gdb/auto-load/usr/lib/${multiarch}/libgobject-*-gdb.py - (dev-bin) /usr/bin/glib-genmarshal - (dev-bin) /usr/bin/glib-mkenums (I think) - (dev-bin) /usr/bin/gobject-query - Gio: - /usr/include/gio-unix-2.0 - /usr/include/glib-2.0/gio/ - /usr/lib/${multiarch}/libgio-2.0.* - /usr/lib/${multiarch}/pkgconfig/gio-*.pc - /usr/share/glib-2.0/dtds/gresource.dtd - /usr/share/glib-2.0/schemas/gschema.dtd - /usr/share/gettext/its/gschema.* - (dev-bin) /usr/bin/gdbus-codegen - (dev-bin) /usr/share/glib-2.0/codegen - (dev-bin) /usr/bin/glib-compile-resources - (dev-bin) /usr/bin/glib-genmarshal - (dev-bin) /usr/share/aclocal/gsettings.m4 - (accompanying runtime library) gio-querymodules - (accompanying runtime library) glib-compile-schemas - formerly GObject-Introspection: see above plus the corresponding man pages. I suspect that the most useful split point for your purposes would be to break out the GObject-Introspection parts, the second-most-useful would be between Gio and everything lower-level, and the third-most-useful would be between GObject and everything lower-level. If we do split the -dev or shared library packages, I would suggest naming the split packages according to the *highest*-level component that they contain (in practice probably Gio or GObject), so that we would still have the option of breaking out even-lower-level parts afterwards without introducing extra-confusing package names. Another possible split point would be to separate the executable tools from the bare minimum that is necessary to include the headers and link with the shared library using pkgconf. However, many (most?) users of GLib are going to want at least some of the executable tools, especially glib-mkenums and glib-genmarshal, so I think that would have limited value. smcv