Bug#1143623: libfwupd-dev fails to coinstall

Control: reopen -1
Control: found -1 2.1.7-3

> fwupd (2.1.7-3) unstable; urgency=medium
> .
>   * debian: move .gir files from libfwupd-dev to gir1.2-fwupd-2.0
>     (Closes: #1143623)

This is not the right solution to the bug reported as #1143623. 
gir1.2-fwupd-2.0 is Multi-Arch: same, just like libfwupd-dev, so it's an 
equally serious bug to be unable to co-install different architectures 
of gir1.2-fwupd-2.0 (for example the :amd64 and :i386 or :s390x 
versions of that package).

Moving the GIR XML to gir1.2-fwupd-2.0 also made gir1.2-fwupd-2.0 
considerably larger, and gave it extra dependencies that are appropriate 
for a -dev package but not for a runtime library package:

     Depends: gir1.2-gio-2.0, gir1.2-gio-2.0-dev, gir1.2-gobject-2.0, gir1.2-gobject-2.0-dev, libfwupd3 (>= 2.1.7)
                              ^^^^^^^^^^^^^^^^^^                      ^^^^^^^^^^^^^^^^^^^^^^

The right solution to #1143623 would be one of these three:

1. (Probably the best short term fix)
    Put the .gir files back in libfwupd-dev, but change the Debian packaging
    so that they're installed to
    /usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0 instead of /usr/share/gir-1.0,
    similar to
    https://salsa.debian.org/gstreamer-team/gstreamer1.0/-/merge_requests/25
    in gstreamer1.0. This way, each architecture will load its own
    architecture-specific version of the GIR XML. This is a
    Debian-specific change: upstream libfwupd would still have to install
    into /usr/share/gir-1.0 by default.

2. (Requires NEW queue)
    Separate the .gir files into a new gir1.2-fwupd-2.0-dev binary
    package. Either install them into
    /usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0, or as a workaround, don't make
    the new binary package Multi-Arch: same.

3. (Longer term) Fix whatever upstream issue is causing the header files
    to be mis-parsed by GObject-Introspection, so that Fwupd-2.0.gir is
    the same on every architecture. Looking at the diff between amd64 and
    i386, it seems like the various enums are not being introspected
    correctly, with constants showing up as having value -1 on amd64
    but 0 on i386, where their real value is G_MAXUINT64:

    --- gir1.2-fwupd-2.0_2.1.7-3_amd64/usr/share/gir-1.0/Fwupd-2.0.gir	2026-08-09 23:35:51.000000000 +0100
    +++ gir1.2-fwupd-2.0_2.1.7-3_i386/usr/share/gir-1.0/Fwupd-2.0.gir	2026-08-09 23:35:51.000000000 +0100
    @@ -14168,7 +14168,7 @@
                  line="270">The device doesn't require verification of the newly installed version.</doc>
           </member>
           <member name="unknown"
    -              value="-1"
    +              value="0"
                   c:identifier="FWUPD_DEVICE_FLAG_UNKNOWN">
             <doc xml:space="preserve"
                  filename="libfwupd/fwupd-device-struct.h"

    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. If you want these sets of flags to
    be representable by the GType system and usable by GObject-Introspection
    languages, then they will need to be limited to 32 bits wide (which would
    be an ABI break).

Sorry to be bringing bad news,
     smcv