Re: build profile proposal: nogir (second try)
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
It's analogous to the choice between one big -dev package (libcairo2-dev,
libwayland-dev) or multiple smaller -dev packages (libportal*-dev) for a
source package with more than one shared library.
The larger, more widely-used and lower-level the library is, the more I
would be inclined to opt for the approach with extra binary packages
- for example splitting out gir1.2-gtk-4.0-dev from libgtk-4-dev
seems more desirable than splitting out gir1.2-shumate-1.0-dev from
libshumate-dev. Separating out the GIR XML is more interesting for
packages that are involved in bootstrapping, or for packages that someone
will frequently want to cross-compile, particularly the ones you'll want
to cross-compile early in the development of a new port when tools like
qemu-user might not be able to target it.
In the case where the GIR XML is in libfoo-dev, asking for it to have
Provides: gir1.2-foo-1-dev means that dependent packages can depend on the
systematic gir1.2-foo-1-dev name, and then will work correctly either way.
The only package where I'm sure that I intend to separate out the GIR
XML in the short term is src:glib2.0, where for historical reasons
gir1.2-glib-2.0 has been built by src:gobject-introspection until
now. I'm most of the way through preparing a version of glib2.0
2.79.x for experimental that takes over gir1.2-glib-2.0{,-dev}
from src:gobject-introspection, and I definitely don't want to fold
gir1.2-glib-2.0-dev into libglib2.0-dev, because GLib's position at the
bottom of the GNOME stack makes it particularly important that we can
still bootstrap and cross-compile it.
smcv
Reply to: