Subject: bug#51270: 28.0.50; xref core package 1.3.0 published, breaks etags

From: Dmitry Gutov <[email-masked]>
Date: Mon, 18 Oct 2021 23:38:59 +0300

Hi!

On 18.10.2021 13:13, Ingo Lohmar wrote:
> 
> This appears to be a packaging bug: The xref core package has changed
> its version number from 1.2.2 to 1.3.0 in
> 35a752863afc9f9075473e34c395d36e0bd18bff.
> 
> The breakage happens because xref 1.3.0 has been published on GNU ELPA
> https://elpa.gnu.org/packages/ (although the details page shows 1.2.2 as
> the latest version, don't know why).  I am using the "eglot" package,
> which requires xref (at a lower minimum version), and when upgrading
> packages this morning, I got xref 1.3.0.

Which version of Emacs are you using? I understand Emacs 26 might have a 
problem with :noinline instructions in the new struct definitions.

But as for loading eieio and defining the xref-location class, the 
top-level version check at the beginning of xref.el should supposedly 
help. It looks like:

(eval-and-compile
   (when (version< emacs-version "28")
     ;; etags.el in Emacs 26 and 27 uses EIEIO, and its location type
     ;; inherits from `xref-location'.
     (require 'eieio)
     (with-no-warnings
       (defclass xref-location () ()
         :documentation "..."))))

> After that, everything related to etags fell apart (company backends,
> after-save hooks to regenerate tags etc) with error messages about
> undefined xref-location classes (and more).

A backtrace example with an error could help as well.

> Brief analysis: The new xref version switches from eieio to
> cl-defstruct, which means that older etags (not a core package) code
> breaks, because it relies on the xref-location class.  This seems to be
> in violation of the comment in xref.el: "Avoid functionality that is not
> compatible with the version of Emacs recorded above." (the version
> "recorded above" is 26.1)
> 
> I am not really clear on how the "core package" idea is supposed to
> work.  One solution would be to "un-publish" xref 1.3.0.  A more general
> approach would introduce semantic versioning to package.el, and the
> above change would require a version 2.0.0 in that world.

Yes, it is definitely a problem.

Semantic versioning wouldn't help, though. Emacs repositories don't 
retain non-latest versions of packages, and we don't have a way to 
specify an upper bound on a dependency either.