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