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

[Yuan Fu]

> 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!