GNU bug report logs -
#51270
28.0.50; xref core package 1.3.0 published, breaks etags
Previous Next
Reported by: Ingo Lohmar <ingo.lohmar <at> posteo.net>
Date: Mon, 18 Oct 2021 17:30:02 UTC
Severity: normal
Found in version 28.0.50
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Wed, 20 Oct 2021 01:05:45 +0300
with message-id <e508cb15-9ae7-bfd6-3a84-aac10d40e53a <at> yandex.ru>
and subject line Re: bug#51270: 28.0.50; xref core package 1.3.0 published, breaks etags
has caused the debbugs.gnu.org bug report #51270,
regarding 28.0.50; xref core package 1.3.0 published, breaks etags
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
51270: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=51270
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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.
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).
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.
In GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
of 2021-09-02 built on t14s-il
Repository revision: 4c49ec7f865bdad1629d2f125f71f4e506b258f2
Repository branch: feature/pgtk
Windowing system distributor 'System Description: Debian GNU/Linux 11 (bullseye)
Configured using:
'configure --without-gsettings --with-pgtk'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PGTK
PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XIM GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: ELisp/l
[...]
Memory information:
((conses 16 1269822 164531)
(symbols 48 46201 11)
(strings 32 209533 58772)
(string-bytes 1 7112283)
(vectors 16 94542)
(vector-slots 8 1961389 54375)
(floats 8 959 1792)
(intervals 56 129413 1921)
(buffers 992 56))
[Message part 3 (message/rfc822, inline)]
On 19.10.2021 20:10, Ingo Lohmar wrote:
> On Tue, Oct 19 2021 00:40 (+0300), Dmitry Gutov wrote:
>> Yes, an update to a more recent emacs-28 should fix it. pgtk is indeed a
>> fair bit out of date.
>>
>> Perhaps we could compare the version more finely to "28.0.60", to cut
>> off most older builds. That 3 month old version advertises itself as
>> "28.0.50", right?
> It does, so the finer comparison should help all but very few edge
> cases. Looking forward to xref-1.3.1 (or something like that)!
1.3.1 is out already, so this will be 1.3.2.
Done, and closing.
This bug report was last modified 3 years and 271 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.