[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#51270: 28.0.50; xref core package 1.3.0 published, breaks etags
From: |
Dmitry Gutov |
Subject: |
bug#51270: 28.0.50; xref core package 1.3.0 published, breaks etags |
Date: |
Mon, 18 Oct 2021 23:38:59 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 |
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.