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

[Dmitry Gutov]

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.