Hi,
On 2024-01-18 00:38, Simon McVittie wrote:
On Wed, 17 Jan 2024 at 23:15:03 +0100, Matthias Geiger wrote:
Am 17.01.24 um 23:00 schrieb Simon McVittie:
> Public GIR XML (Foo-1.gir) is normally in the -dev package alongside the
> C headers, but recent versions of gobject-introspection define a canonical
> virtual package name gir1.2-foo-1-dev which can either be a Provides on
> the -dev package or an independent binary package.
Does this mean we should should split out the .gir XML files from
existing
source packages into a separate gir1.2-foo-dev (in the long run) ?
That's a good question, and I don't have an easy answer for it. The
tradeoff is:
- having the GIR XML in libfoo-dev means fewer binary packages and
therefore smaller Packages metadata;
- having a separate (non-virtual) gir1.2-foo-1-dev means we can
"cleanly"
turn off GIR/typelibs in cases when they're not needed, and means
libfoo-dev is a bit smaller and with fewer dependencies
maybe it makes sense to get back to Helmut's original [message] that
Simon linked to a few mails ago:
Why?
gobject-introspection is one of the few and high popcon components that
poses resistant to cross compilation. gir packages are often added to
existing source packages for e.g. libraries and their presence makes
cross building fail. Often enough, these gir packages are not needed
for
a particular application, so skipping them would allow cross building
the library. The profile also allows fixing cross build problems in
packages shipping typelib files such that when we get a solution for
typelib generation, those packages will not have other bugs.
[message] https://lists.debian.org/debian-devel/2023/04/msg00056.html
When deciding for trade-offs we should probably go back and look at the
"Why" for this whole effort. Back when Helmut wrote this message, Simon
hadn't yet implemented the mechanism that would use qemu to allow for
cross-compilation to supported architectures. For when it works, it
works *really* well. Before Simon's efforts, I had to build packages
using gobject-introspection "natively" using qemu user-mode emulation to
get foreign architecture binaries. In my situation this took 1.5 hours.
With what is currently in Debian unstable, I am able to compile the same
packages in under 4 minutes. This is a 20-fold speed-up (Thank you Simon
and Helmut!! <3). But of course there are situations where the qemu
method is not applicable. Maybe nogir build profile and the package
splitting should be limited to carefully selected situations where it is
deemed necessary by bootstrappers or cross-builders that doing so has
some real-world benefits? I don't think it makes much sense to add nogir
profiles and package splits where they do not serve much of a purpose.
Doing so would mean to just get the cost of doing so without any
benefit.
Thanks!
cheers, josch
