Your message dated Mon, 17 Mar 2025 12:21:02 +0000
with message-id <[email protected]>
and subject line Re: Bug#1030223: gobject-introspection mini-policy: make
cross-compilation possible
has caused the Debian Bug report #1030223,
regarding gobject-introspection: make cross-compilation possible
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1030223: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030223
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: gobject-introspection
Version: 1.74.0-3
Severity: wishlist
File: /usr/share/doc/gobject-introspection/policy.txt.gz
Tags: trixie sid
At the moment, a typical introspected library (I'm using libflatpak as my
example) has this layout, where the files marked [*] are generated by
GObject-Introspection:
libflatpak-dev
/usr/include/flatpak
/usr/lib/*/libflatpak.so
/usr/lib/*/pkgconfig/flatpak.pc
/usr/share/gir-1.0/Flatpak-1.0.gir [*]
libflatpak0
/usr/lib/*/libflatpak.so.0.*
/usr/lib/*/libflatpak.so.0
gir1.2-flatpak-1.0
/usr/lib/*/girepository-1.0/Flatpak-1.0.typelib [*]
GObject-Introspection gets some of its information by parsing the source
code, and that's fine. However, it gets other information by introspecting
the just-built libflatpak.so.0 (hence its name): linking a small executable
to libflatpak.so.0, and running it. When doing "true" cross-compiling
(without the ability to run host executables via qemu-user or similar),
this is not possible.
Ideally, when cross-compiling Flatpak, we'd prefer to build it with
a build profile like cross or nogir that has the effect of building it with
./configure --disable-introspection, which disables the generation of the
files marked [*]. However, that would make this build profile cause a
functional change to the contents of libflatpak-dev, which is strongly
discouraged.
If we separated the GIR XML into a new binary package, perhaps named
gir1.2-flatpak-1.0-dev or something like that, then we would be able to
turn off both gir1.2-flatpak-1.0 and gir1.2-flatpak-1.0-dev under the
nogir build profile (similar to how the noudeb, nocil and noinsttest
profiles work), making cross-compilation possible (as long as you don't
care about GObject-Introspection-based language bindings).
I think this would require changes to dependent packages if they make
use of the GIR XML (because build-depending on libflatpak-dev would
no longer be enough, and it would also be necessary to build-depend on
gir1.2-flatpak-1.0-dev <!nogir> or similar). If so, this would have to
be done on a package-by-package basis, with dependent packages changed
before their dependency. A migration path would be to add
Provides: gir1.2-flatpak-1.0-dev (= ${binary:Version}) on libflatpak-dev.
A side benefit of this would be that we could separate out the GIR XML
that is provided by src:gobject-introspection (#859013) into one or more
similar gir1.2-*-dev packages.
smcv
--- End Message ---
--- Begin Message ---
Version: 1.83.4-1
gobject-introspection in trixie can cross-compile GIR XML and typelibs
if qemu-user emulation of the host architecture is available on the
build architecture.
Also, with the gobject-introspection in trixie, packages that want to
support the nogir build-profile, which skips generation of GIR XML and
typelibs completely, can opt-in to it.
See debian/gobject-introspection.README.Debian
(file:///usr/share/doc/gobject-introspection/README.Debian.gz) for full
details.
smcv
--- End Message ---
