bug#70438: Emacs error 6 abort when starting rust-ts-mode

[Yuan Fu <casouri@gmail.com>]

> On Apr 25, 2024, at 6:19 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Stefan Heitmann <sh@bytekomplex.de>
>> CC: "70438@debbugs.gnu.org" <70438@debbugs.gnu.org>
>> Date: Thu, 25 Apr 2024 11:24:13 +0000
>> 
>> Thank you very much for your help...
>> 
>> I think I understand roughly the issue and it makes sense that you can't do anything here... But I think, I could file another bug report for the repo maintainer of the arch package 😉
> 
> Yes, please.

In the GitHub issue that tracks this incident, the author made clear that maintaining ABI versioning correctly is beyond their ability right now. So I think we should pin the tree-sitter version. But then IIUC we can only bump tree-sitter version with each Emacs release? This is a bit unfortunate but better than crashing Emacs.

This also brings me to the versioning of tree-sitter grammars—they really do change often, we should really consider pinning their version in some way. The current catch-up game we play can’t be scalable.

Yuan

Quote:

>> Just so that this is clear to me: The solution to the immediate problem would be for the relevant Linux distros to issue a new Emacs package?

> I really think that in order to provide a reliable end-user experience, and prevent issue like this, Emacs should just statically link a particular version of Tree-sitter.

> If some Linux distros mandates that all libraries, no matter how small, must be distributed as dynamic libraries (which is just... staggeringly impractical IMO), then the Emacs package should specify a particular version of the Tree-sitter package to use - not a version range.

>> I think we have to commit to not using the semver version in our library names, and to follow libtool-compatible rules for selecting a SONAME instead.
>> 
> I agree with this. Ideally, we should set up tooling to automatically bump the soname on breaking ABI changes. But if any Emacs package maintainer is seeing this issue - we do not yet have this tooling - this library is maintained by a small team, and may not have perfect ABI stability! Consider taking a more conservative approach to dependency versioning, so that end users don't have to deal with situations like this!