Bug#1030223: gobject-introspection mini-policy: separate GIR XML from -dev package to make cross-compilation possible?

[Helmut Grohne]

Hi Simon,

On Wed, Feb 01, 2023 at 10:39:30AM +0000, Simon McVittie wrote:
> 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.

I agree in principle. The problem with changing the contents of
libflatpak-dev is twofold. For one thing, a binary package name (such as
libflatpak-dev) implicitly defines an interface and a contract between
cooperating packages. The present interface includes the gir files and
having them vanish from libflatpak-dev on specifying a nogir profile
would break the interface contract. The other reason for the
discouragement is being able to validate profiles using reproducible
builds.

> 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).

Such separation solves both the interface contract and the
reproducibility aspect. Let me propose another alternative. Rather than
have gir1.2-flatpak-1.0-dev be a real binary package, we can provide it
as a virtual one from libflatpak-dev. The mini-policy would then have to
be updated such that using the gir files requires depending on a
gir*-dev package and that a dependency on the regular lib*-dev package
is insufficient. When enabling the nogir profile, the virtual package is
removed thus no interface is broken. This variant still breaks
reproducibility of course.

> 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.

In essence, I am saying that this migration path could be the final
result thus eliminating the NEW trip, but not eliminating the need to
update dependent packages. Note that dpkg resolves profiles in binary
package relations at build time, so you can write:

    Provides: gir1.2-flatpak-1.0-dev (= ${binary:Version}) <!nogir>

> 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.

Of course, a separation by real binary packages would not be prohibited.

In your second mail, you propose storing pre-built gir files in debian/.
I dislike this proposal, because it poses continuous extra effort for
maintainers. We already struggle with symbols files and shouldn't add
another variant of them. I understand that this looks attractive from a
cross builder's point of view, but I think cross building should bear
the effort here, not gnome package maintainers. I hope you can agree
with that.

Given this, would you agree that nogir would make sense right now as a
non-reproducible profile? It still requires updating all reverse
dependencies, yeah, but we can do so in parallel. For the migration
period, we would have missing dependencies in the presence of nogir
profiles, but these would solely affect users of the nogir profile,
which would be the ones to report and fix such missing dependencies.
Regular users (and buildds in particular) would never experience issues
due to such missing dependencies.

Helmut