On Tue, 27 Feb 2024 at 23:07:33 +0100, Matthias Klose wrote:
> On 23.02.24 22:10, Jeremy Bícha wrote:
> > Since glib and gobject-introspection have migrated out of
> > noble-proposed, is there still a need to keep this bug open?
>
> Suppose you would start again building glib2.0 (and depending packages) for
> all supported Python versions, would that work with the current
> gobject-introspection?
I'm not sure I understand the question. When you say "start again" do
you mean bootstrapping (starting from the beginning), or do you mean
"resume doing something that we did in the past but we now don't"?
If you mean bootstrapping, there is a chain of builds that I believe would
work: build glib2.0 with -Pnogir, use it to build gobject-introspection,
and use that to rebuild glib2.0 with no special profiles.
If you mean "resume doing what we did in the past", I think that
question is based on a false assumption. You might be imagining that
gobject-introspection provides a public Python library, like python3-gi or
python3-dbus, which should be available for every supported Python version
in parallel, but that isn't the case: its role in the Python ecosystem is
more like borgbackup or vim, so it's correct for gobject-introspection-bin
to have a dependency on: python3 (>= current), python3 (<< next).
As far as I know, glib2.0 has never done a build pass or byte-compilation
for each supported Python version in parallel. Its only Python parts
are in libglib2.0-dev-bin (gdbus-codegen and other CLI tools) and
libglib2.0-dev (gdb extensions), both of which are only relevant to
the default Python version, and it has no Python extensions written in
C, only "pure Python" code. The only interface to any of this is by
running tools in /usr/bin, and the fact that they happen to be written in
Python is an implementation detail. It doesn't need any manual action
to be taken when a new Python version is introduced, unless there are
incompatibilities. Ideally the private modules used by gdbus-codegen get
byte-compiled when the default Python version changes, but that's done
automatically, and there would be no particularly significant impact if
it didn't happen.
As far as I know, gobject-introspection has also never been built once
per supported Python version, only for the default Python version. Its
Python part is a private library shared between several of its CLI tools,
and again, the only public interface is via running tools in /usr/bin.
Unlike glib2.0, the private library includes a C extension, so it does
need to be binNMU'd when the default Python version changes.
python3-gi from src:pygobject (a Python library that uses libgirepository)
*is* built for all supported Python versions, and it does provide a
public API to Python callers; but it can do that regardless of what
Python version happens to be used internally by gobject-introspection's
CLI tools. Is that perhaps the library you were thinking of?
If I understand correctly, the usual progression for adding a new Python
version goes like this:
1. Start with only python3.11 supported and default
2. Add python3.12 as supported but non-default
3. binNMU python3-gi and similar packages so they support both 3.11 and 3.12
4. Make python3.12 the default, with python3.11 still supported
5. binNMU gobject-introspection and similar packages for the new default
6. Drop support for python3.11
7. binNMU python3-gi and similar packages so they only support 3.12
python3-gi is involved in steps 3 and 7 (the same as e.g. python3-dbus),
but gobject-introspection is only involved in step 5 (the same as e.g. vim).
Does that answer your question?
smcv
