Re: build profile proposal: nogir (second try)

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