Re: build profile proposal: nogir (second try)
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
Reply to: