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
