On Tue, 27 Aug 2024 at 14:22:58 +0200, Helmut Grohne wrote:
> > I suspect that the most useful split point for your purposes would be to
> > break out the GObject-Introspection parts, the second-most-useful
> > would be between Gio and everything lower-level, and the third-most-useful
> > would be between GObject and everything lower-level.
>
> As far as I understand things, splitting GObject-Introspection would
> vaguely resemble the bookworm-state of things (with different package
> names). Would you agree to that characterization?
Yes, I think so: the relationship between the higher-level and lower-level
parts of src:glib2.0 would be similar to the relationship between
gobject-introspection and libglib2.0-dev in bookworm.
> As you say, we should name it
> according to the highest level component, so I guess that libglib2.0-dev
> would be replaced by libgobject-introspection-dev and another library
> containing what libglib2.0-dev formerly contained minus
> GObject-Introspection. Would that new package be called libgio2.0-dev?
The concept is right here but I think that naming is confusing, because
gobject-introspection continues to be a separate source package.
src:glib2.0 has taken over (equivalents of) a library and some of the
tools from src:gobject-introspection, but I believe the current plan
is that g-ir-scanner will continue to be in src:gobject-introspection
forever.
The affected tools are:
in gobject-introspection | in glib2.0 | needs cross-exe-wrapper
--------------------------|-------------------------|------------------------
g-ir-annotation-tool | (none) | no?
g-ir-compiler | gi-compile-repository | yes, at top level
g-ir-generate | gi-decompile-typelib | yes, at top level
g-ir-inspect | gi-inspect-typelib | yes, at top level
g-ir-scanner | (none) | yes, internally
and it is those tools (except for g-ir-annotation-tool) that need to
be of the host architecture, using qemu or a similar cross-exe-wrapper
during cross-compilation.
I would prefer the package providing libgio-2.0.so and gio-2.0.pc to be
libgio-2.0-dev rather than libgio2.0-dev, because that's a closer match for
its pkg-config name.
The introspection tools need to be split between a M-A: same package that
contains x86_64-linux-gnu-gi-compile-repository and so on, and a M-A: foreign
package that contains the actual binaries gi-compile-repository and so on.
libgobject-introspection-dev would be a confusing name for either of these,
both because it wouldn't contain development headers for any C library (those
are already in libgirepository-2.0-dev) and because src:gobject-introspection
is something different.
Perhaps the M-A: same package could be girepository-tools, and the
M-A: foreign package could be girepository-tools-bin, mirroring how pkgconf
is laid out?
It would be technically possible to use libgirepository-2.0-dev as the
M-A: same package, and create a new libgirepository-2.0-dev-bin as the
M-A: foreign package; but I think that would be a mistake, because that
would be conflating the API-versioned girepository library (which is
used by these tools, and by future versions of language bindings like
PyGI and gjs) with the non-versioned names of the tools. If the library
is bumped to API version 3.0 in future (more likely to happen here than
in the rest of GLib, because it's less mature), gi-compile-repository
still has an unversioned name and we will presumably want it to end up
in a package with a similarly unversioned name.
So, perhaps this layout?
libglib2.0-dev: metapackage with complete GLib development files
|- M-A: same (install for host)
|
|- Depends: libgio-2.0-dev: development files for GLib, GObject, GIO
| |- M-A: same (install for host)
| |- Provides: libglib-2.0-dev
| |- Provides: libgobject-2.0-dev
| |- optionally Provides: libgmodule-2.0-dev for completeness
| |- optionally Provides: libgthread-2.0-dev for completeness
| |
| \- Depends: libgio-2.0-dev-bin: development utilities for GLib, GObject,
GIO
| |- M-A: foreign (install for build)
| |- Breaks/Replaces: libglib2.0-dev-bin (<< this)
| \- Depends: python3, python3-packaging (needed by gdbus-codegen)
|
\- Depends: girepository-tools
|- M-A: same (install for host)
|- Breaks/Replaces: libglib2.0-dev (<< this)
|
\- Depends: girepository-tools-bin
\- M-A: foreign (install for build)
\- Breaks/Replaces: libglib2.0-dev-bin (<< this)
libglib2.0-dev-bin could disappear, or could exist as a transitional
package depending on libgio-2.0-dev-bin and girepository-tools-bin.
or libglib2.0-dev could probably just Provide it.
The Provides shown above indicate where the packages could be split again
if we find that we need a finer granularity in the future, although
I think I'd prefer not to do that unless you anticipate that we will
need it.
In the layout I'm suggesting, libgio-2.0-dev, the package that e.g. qemu
would build-depend on, still needs python3 and python3-packaging for
the build architecture (and possibly more Python in the future). Do
you anticipate that being a problem for you in future? Most of the
GNOME-adjacent world needs python3:native during build *anyway*, either
for Meson or in ad-hoc build scripts that would still be necessary
if replacing Meson with Muon, so I'm hoping that isn't going to make
anything worse in practice.
> Given that libglib2.0-dev has more than 3000 reverse dependencies, I
> think we need to continue to provide it with that name and it needs to
> provide the maximum featureset (or we cause an annoying number of
> FTBFS).
Yes. I also think that, unlike the situation with src:gobject-introspection
(where libgirepository1.0-dev is vaguely deprecated because it cannot be
multiarch co-installable for backwards compatibility reasons), we should
probably be encouraging dependent packages to continue to have
Build-Depends: libglib2.0-dev for simplicity, unless they are part of the
bootstrap set or otherwise particularly interesting to cross-compile.
Rationale: libglib2.0-dev is the equivalent of other distributions' single
GLib development package (e.g. glib2-devel in Fedora), and upstreams are
going to expect that the whole thing is present unless they have special
reasons to be careful about their dependencies.
> You also take issue with the need to go through NEW and I think we can
> get away without going through NEW by adding packages in build profiles.
This has the disadvantage that maintainers of packages whose dependencies
need to be reduced / made more specific cannot verify that their new
dependencies are sufficient, except by literally doing the bootstrap.
I'm OK with putting glib2.0 through NEW for this, but I'd prefer it to
be only once, rather than iteratively breaking up the package into smaller
and smaller parts in several trips through NEW (which would be more delay,
and more rolls of the dice for the ftp team deciding that d/copyright is
insufficiently thorough and threatening to remove GLib as a result).
Getting the split and the naming correct once, and then doing one trip
through NEW when it's ready, would also minimize the chance of being
painted into a corner by choosing package names that end up being confusing
after several iterative package splits have been done.
> The most fundamental choice in this is whether glib2.0 is to be built in
> the cross phase of architecture bootstrap or in the native phase.
I believe it should be cross-buildable if built with the nogir profile,
which you already need to do during bootstrapping anyway, to avoid a
dependency on src:gobject-introspection which depends on src:glib2.0.
Am I right in thinking that the sticking point here is: in addition to
being able to cross-build, a requirement that you place on packages from
the cross phase is that the runtime dependencies of anything that is
needed during the cross phase must be limited to packages that were
built earlier in the cross phase? And the reason you have a problem with
src:glib2.0 now is libglib2.0-dev's dependency on qemu?
> Practically speaking, I expect [requiring cross-building from an
> architecture of a matching endianness] to be another nail in big
> endian's coffin. I'd have to source a big endian machine for QA
> (difficult). But then, all of the new architectures have been little
> endian, so maybe big endian really is dead already?
I think it is, really: when even the PowerPC family has moved to
little-endian, I think that's a sign that the industry has given up on
big-endian.
The fact that you say sourcing a big-endian machine for QA would be
difficult also seems like a pretty good sign that big-endian is dead.
smcv
