On Thu, 18 Jan 2024 at 11:08:30 +0100, Helmut Grohne wrote: > On Wed, Jan 17, 2024 at 11:38:09PM +0000, Simon McVittie wrote: > > The only package where I'm sure that I intend to separate out the GIR > > XML in the short term is src:glib2.0 > > How annoying would it actually be to split this to a > different source package?
Really quite annoying. The reason I'm integrating the GIR build into the glib2.0 source package now is that upstream have done the same, which allows the different parts to become increasingly tightly-coupled in future (and I don't think upstream would be putting in this work if they didn't intend to make use of that ability). A snapshot of glib2.0 that takes over the GIR build is waiting in NEW for ftp team approval: https://ftp-master.debian.org/new/glib2.0_2.79.0+git20240119~62ee8bf6-1.html https://salsa.debian.org/gnome-team/glib/-/tree/debian/2.79.0+git20240119_62ee8bf6-1?ref_type=tags It's an upstream git snapshot rather than a formal prerelease, because quite a lot is still changing in this area, and packaging a snapshot seemed more applicable to future versions than backporting selected fixes into the 2.79.0 prerelease; but this is going to be stable API/ABI in GLib 2.80, due for release in March. To make GLib properly robust I think we will want the ability to use lockstep version dependencies here, but uploading two source packages (with identical source code and different packaging) every time there is a glib2.0 bug fix, and breaking the release team's ability to binNMU them independently, seems like a high price to pay for making bootstrap a little more automatic. If porters are interested in making bootstrap automatic despite cycles like this one, I think a better route would be to be able to have a list of suggested bootstrap steps and build-order considerations, either centralized in some sort of cross infrastructure or distributed among packages. I'd be fine with adding something like this to glib2.0, for example, if it helped: Bootstrap-Before: dbus, gobject-introspection Bootstrap-Build-Profiles: nogir, nocheck, noinsttest Or, if we separated the nogir build profile that I'm proposing here into two, something like this: nogir-changing-content can change content: Y ("unreproducible"/"unsafe" profile) can change package set: Y nogir can change content: N ("reproducible"/"safe" profile) can change package set: Y would that allow automatic bootstrapping infrastructure to figure out that it was both safe and desirable to build glib2.0 with nogir? (I infer that there must be some sort of infrastructure that knows that it's safe to build packages with "nocheck,noinsttest", otherwise glib2.0 and dbus are already in a cyclic dependency for their test suites.) > given that it > formerly was part of src:gobject-introspection, it cannot be unworkable The fact that this worked in gobject-introspection was a big exception to more usual practices, and it worked by copy/pasting and committing all the doc-comments from glib2.0 into a large "source" file in gobject-introspection. I don't think anyone really wanted this, but it was considered a necessary evil to break cyclic dependencies. As a result of that workaround, project members with a particularly uncompromising definition of preferred forms for modification have already required us to duplicate the rest of the src:glib2.0 source into src:gobject-introspection (implemented as a secondary orig.tar.xz), and then duplicate all of its copyright information in gobject-introspection's d/copyright, which was rather unwieldy to say the least. I personally think a compilation of doc-comments in editable text form is an entirely valid form of source from which Debian users can exercise all of their Free Software rights, but it seemed that there was no consensus on this. Doing a bunch of tedious administrative work and increasing the size of the gobject-introspection source package by 500% seemed more likely to succeed than getting into a fight about the semantics of the DFSG with preferred-form-for-modification maximalists, so I did what I had to do. I do have limited patience for doing extra volunteer work that I think is neither fun nor constructive, though, so I would prefer to remove the situation that made this necessary by making use of the tools that we have (including build profiles and cross-compiling). I'm sorry if that's causing extra work for your use-case. smcv
