Paul Wise <p...@debian.org> writes: > On Fri, 2022-08-26 at 11:58 +0100, Simon McVittie wrote:
>> For instance, take rust-glib-sys, a package of Rust bindings for the >> GLib library, which is one of the libraries whose handling prompted >> this thread. > 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). Speaking as an upstream maintainer who historically has maintained language bindings for a package together with that package (remctl), I can tell you that this is a bad idea, I would tell my past self to never go down this path, and that maintaining each language binding as a separate upstream release is a superior technical solution. This is unintuitive! I believed the opposite for many years! But it turns out that maintaining language bindings as part of a single combined source package is an incredibly difficult thing to attempt to do in the upstream build system, and it is getting more difficult by the day. Each language ecosystem has its own build system, and many of them are undergoing rapid development. Each language now also has its own archive to which build artifacts should be uploaded, often including pre-built binary artifacts for major platforms, and doing this with a combined build system from a single source package is quite difficult. All of the tools are oriented around a single package building for a single language, with all of the build system configuration for that language at the top level of the package. It's *possible* to do this. I have for years supported bindings for four languages plus the C source in remctl. But it's hard; I have personally spent multiple hours keeping this working, hours that were not spent on the software itself or even on the build system but just on integration problems between the various build systems mushed together into the same release. There's very little payoff for this work and it's contributed to not integrating some language bindings or other implementations, such as Java. I haven't yet had the time to do this, but I plan on separating remctl into five separate upstream releases for different languages. This will also, ironically, help in Debian, since it will mean that the remctl source package doesn't tie together language transitions for four different languages. remctl doesn't have the specific problem that Simon is pointing out with the definition of what source code is, so it's unaffected by the point of this thread. But I think it's important to note that upstreams do things like this for good reasons, and undoing them may mean that someone spends a bunch of time and effort, on an ongoing basis, working around problems that upstream has wisely avoided and doesn't think should need to exist. It's very hard to find motivation or volunteers for that kind of work! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
