On Sat, 27 Aug 2022 at 09:01:01 +0800, Paul Wise wrote:
> > I don't think building from the least-derived form is always the
> > right thing to do.
>
> Personally, I believe that instances of that represent bugs in how the
> upstream source trees and build processes are organised.
While I'm flattered that you think I have the level of control required
over upstream projects to be able to demand that they change their
procedures in this way, I'm just a relatively minor contributor doing
my best. If the bar for being a Debian maintainer is set at "must be
influential enough to coerce the upstream project into behaving as we
want, against other developers' wishes", then I think we will have an
unsustainably small contributor base.
If I recall correctly, there have been vague plans to integrate
GObject-Introspection with GLib for about a decade (in order to break
the circular dependency that GObject-Introspection depends on GLib, while
the interface description for GLib is conceptually part of GLib but must
be generated using GObject-Introspection), so if there was not a barrier
to doing that, I'm sure it would already have happened. I don't know the
details, but to the best of my understanding the major objection is that
GLib essentially cannot ever break API/ABI without extensive disruption,
while GObject-Introspection is not felt to be sufficiently mature to
be able to say with confidence that it can live up to that standard
of stability.
However, GObject-Introspection has worked approximately the way it
currently works since at least 2008, and was apparently fine. I am less
familiar with the Rust bindings, but I believe they've worked the same way
they currently work since they were introduced to Debian in 2018. What has
changed? Have the goalposts been moved? I share Sebastian's concern that
if upstreams are led to believe that something has been fine for multiple
years, demanding that they put a significant amount of work into changing
how they operate is unlikely to lead to positive results. I already have
to spend a significant amount of time defending "weird Debianisms" even
in sitations where there is a compelling technical reason for what we do;
upstream goodwill is a finite currency, and I think we should prioritize
spending it in the ways that will give us the best return on investment.
Requiring GLib and GObject-Introspection to be upgraded in lockstep would
also limit our ability to test new versions of GLib in experimental,
which is something I have been putting a significant amount of work into
in recent years: at an early stage in the GLib release cycle, there is
usually no corresponding version of GObject-Introspection yet. If we
do not test development versions of important libraries like GLib, then
we will be stuck in the situation of always catching up with upstream,
and will be unable to respond to upstream changes quickly enough to have
influence over whether they are accepted, reverted or adjusted. If we
claim to be maintainers rather than mere packagers, which we do, then
we need to spend less time working with branches where it is already
too late to make significant changes.
> I feel like the right way to organise this upstream is for GLib itself
> to be building the bindings for itself (as Bastian Roucariès suggests).
Meanwhile, the language bindings for GLib and most GLib-based libraries
(for Rust, Python, JavaScript, Perl, Haskell, C++, etc.) have always been
separate from GLib itself. There are broadly two categories: the ones for
dynamic languages like Python, Perl and JavaScript that are brought into
existence at runtime on a just-in-time basis, which are not a problem in
this context because there is already an expectation that these languages
are dynamic, and the ones for compiled languages like Rust, Haskell and
C++, which get compiled and have a fixed API/ABI for all subsequent uses.
I for one am grateful that it is possible to be a GLib maintainer without
being proficient in Rust, Haskell, C++, D, Pascal and whatever other
statically-compiled languages people want to support. If GLib upstream
were to integrate the Rust bindings into GLib, therefore requiring
maintainers to be proficient in Rust, then I would no longer be able to be
an effective GLib maintainer. Even if I was proficient in Rust, requiring
maintainers to also know (for example) Haskell seems unrealistic.
I know some people would consider me to be irresponsible for not yet having
learned Rust to an expert level, and I apologise for only having a finite
amount of time available for Debian; but there are too many things in
my queue already, and the higher we put the bar for being a maintainer,
the smaller our potential contributor base gets.
As well as the scalability problems inherent in having each library
be responsible for explicitly supporting every language, the same
stability concerns as for GObject-Introspection apply here: GLib is a
mature library with a long-term stable API/ABI, but its Rust bindings
are relatively new and cannot guarantee stability on a scale of decades
(they haven't yet *existed* for decades).
The glibmm bindings into C++ are in a similar situation of being less
long-term-stable than GLib itself, and have had at least two intentional,
parallel-installable API/ABI breaks during the lifetime of GLib 2.x
(glibmm2.3 -> glibmm2.4 and glibmm2.4 -> glibmm2.68) even though GLib
itself has not. I expect that the Rust bindings will have to behave
similarly over time, to avoid being constrained by whichever early design
decisions turn out with hindsight to have been a poor choice.
> Alternatively, if the GLib bindings really need to be separate, then
> GLib could build the XML description of its APIs, include that in a
> package, then rust-glib-sys build-dep on that, include a Built-Using
> header and get binNMUed after every GLib update.
I think I explained earlier in this thread why it is not desirable
for the API of a rust-glib-sys package of the same upstream version to
change depending on the version of GLib that it happens to have been
built against.
smcv
