Last year, Helmut Grohne proposed a nogir build profile to help with
cross-compiling the GLib ecosystem:
<https://lists.debian.org/debian-devel/2023/04/msg00056.html>.
After some discussion on #1030223, I have a revised proposal, with the
same name but slightly different rules:
profile name: nogir
content changes: Y/N (ideally N)
package set changes: Y
description: Disable GObject-Introspection bindings (.gir, .typelib).
See the GObject-Introspection mini-policy for details.
For background, GObject-Introspection provides machine-readable
information about C/C++ code that follows GLib's conventions. There are
two formats: GIR XML is a text format with full information for compiled
bindings (C++, Rust, Haskell), and typelibs are a more efficient binary
format with a subset of that information for dynamic bindings (Python,
JavaScript, Perl). There is a compiler to do the lossy conversion from
GIR XML into typelibs, but creating the GIR XML is the part that has
dependencies we sometimes want to avoid, so disabling the typelibs but
leaving the GIR XML in place is not useful.
Public typelibs (Foo-1.typelib) are already shipped in their own package,
gir1.2-foo-1, so they are easy to disable with a build profile.
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.
Here is the draft text that I added to the GObject-Introspection
mini-policy in 1.78.1-11:
----
Source packages that build GIR XML and typelibs may implement the nogir
build profile. This will usually be desirable for libraries that can be
used directly from C/C++ code without needing to use GObject-Introspection.
It will usually not be useful to implement the nogir build profile in
packages where GObject-Introspection is a functional requirement for using
the package, such as gnome-shell.
Ideally, the nogir build profile should disable the build of gir1.2-* and
gir1.2-*-dev packages, and disable all build-dependencies on the
gobject-introspection toolchain and gir1.2-*-dev packages, without
affecting the contents of any other binary package, in particular lib*-dev.
When implemented like this, nogir is a "safe" or "reproducible" build-profile.
However, for many pre-existing source packages, separating GIR XML
from the lib*-dev package into a new gir1.2-*-dev package would be an
incompatible change that needs to be coordinated with dependent packages,
because previously-correct dependent packages would begin to fail to build
from source until they add gir1.2-*-dev to their Build-Depends (even if
the package was built without the nogir profile and the dependency is
a native build). It would also require manual processing by the Debian
archive administrators, to approve the new binary package name.
To mitigate those factors, if the GIR XML is included in a lib*-dev
binary package, the nogir build profile may remove the GIR XML from
that package. The resulting binary package must drop any Provides
matching gir1.2-*-dev that it would have had when built normally. This
will often be automatic: if dh_girepository is used, ${gir:Depends}
and ${gir:Provides} will automatically be emptied for packages that do
not contain any GIR XML or typelibs.
If this is done, dependent packages will continue to build successfully
against any dependency that was not built with nogir, but will require
changes (namely adding Build-Depends: gir1.2-*-dev <!nogir>) in order to
be sucessfully buildable with dependencies that were built with nogir.
----
I did wonder whether this should be two separate build profiles, but
that seems like it's probably unnecessary complexity.
smcv
