Bug#1143623: libfwupd-dev fails to coinstall

On Mon, 10 Aug 2026 at 15:25:26 +0200, Chris Hofstaedtler wrote:
>>    It looks like libfwupd is doing things that are not compatible with
>>    the assumption made by GLib's GType system: it's setting the UNKNOWN
>>    value for various enums to G_MAXUINT64, but the GFlagsValue data
>>    structure represents members of a set of flags as guint (an alias for
>>    unsigned int, 32 bits on all Debian platforms), so this is simply not
>>    representable in the GType system.

(I could be wrong about the specifics here, I don't actually know how 
libfwupd works internally - it seems to involve Rust code-generation, 
and that isn't a language that I know.)

>... should gobject-introspection fail on such things? It seems to me
>that such a type violation would be a hard fail in other language
>ecosystems.

Presumably it'll be some combination of historical reasons, not wanting 
to break existing code, wanting to provide language bindings for the 99% 
that is usable even if a minority of it is unusable, or bugs, 
potentially unfixable ones.

If GObject-Introspection is getting this information from the GType 
system, then the top 32 bits have probably been lost altogether by the 
time GObject-Introspection sees it, so GObject-Introspection likely 
doesn't have the opportunity to know that there was a problem. The 0/-1 
difference between architectures could indicate that out-of-range values 
are being truncated differently, or stuffed into a `long`-sized field 
and read back differently, or something?

Or if GObject-Introspection is getting this information from the C 
source code, it could be making assumptions about "normal" enums/flags 
that are not easily checkable. Parsing the C source to get enum/flags 
values in a fully correct way is unlikely to be feasible without a 
complete implementation of the C preprocessor and half of the compiler, 
which is not something that's realistically available. But if an 
enum/flags value can't be parsed, detecting that situation and refusing 
it is just going to make existing software FTBFS, which would certainly 
detect problems but would presumably be considered an unacceptable 
regression (leading to the improved version of GObject-Introspection 
being rejected from inclusion in Debian until all reverse-dependencies 
have been made compatible with it, which could require them breaking 
API/ABI). So I'm not sure that this really helps us.

If programs that use libfwupd via language bindings happen to not use 
these particular constants (which I suspect to be the case in practice, 
otherwise they wouldn't work) then those programs could still work. I 
know this is not an ideal situation, but imperfect software exists and 
is sometimes a necessary part of our OS distribution.

For the GType code path, GLib could probably arrange for some 
G_STATIC_ASSERT() to be added to the generated GType registrations, to 
make it refuse to register enums/flags types that can't interoperate 
with GType/GValue due to being larger than int; but if it did that, that 
would just make existing software like libfwupd FTBFS until it breaks 
ABI, which again would certainly detect problems but would presumably be 
considered an unacceptable regression. So, again, I'm not sure that 
really helps us. The least-disruptive way to do this would probably be 
to gate it on a minimum GLIB_VERSION_MAX_ALLOWED. If someone wants to 
work on that, the place to discuss it would be with GLib upstream, 
<https://gitlab.gnome.org/GNOME/glib/>.

I'm aware that the ecosystem is not perfect, and I'm sorry. 
Unfortunately, making myself feel more guilty doesn't provide more hours 
in a day, and I'm already responsible for more topics than I can meet 
community expectations for, so I have to say that some things are 
outside my scope.

     smcv