* bug#51270: 28.0.50; xref core package 1.3.0 published, breaks etags
@ 2021-10-18 10:13 Ingo Lohmar
2021-10-18 20:38 ` Dmitry Gutov
0 siblings, 1 reply; 6+ messages in thread
From: Ingo Lohmar @ 2021-10-18 10:13 UTC (permalink / raw)
To: 51270
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))
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#51270: 28.0.50; xref core package 1.3.0 published, breaks etags
2021-10-18 10:13 bug#51270: 28.0.50; xref core package 1.3.0 published, breaks etags Ingo Lohmar
@ 2021-10-18 20:38 ` Dmitry Gutov
2021-10-18 21:12 ` Ingo Lohmar
0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Gutov @ 2021-10-18 20:38 UTC (permalink / raw)
To: Ingo Lohmar, 51270
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#51270: 28.0.50; xref core package 1.3.0 published, breaks etags
2021-10-18 20:38 ` Dmitry Gutov
@ 2021-10-18 21:12 ` Ingo Lohmar
2021-10-18 21:40 ` Dmitry Gutov
0 siblings, 1 reply; 6+ messages in thread
From: Ingo Lohmar @ 2021-10-18 21:12 UTC (permalink / raw)
To: Dmitry Gutov, 51270
On Mon, Oct 18 2021 23:38 (+0300), Dmitry Gutov wrote:
>> 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.
I am using the feature/pgtk branch, which is currently based on an older
master (roughly 3m ago) it seems.
> 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 "..."))))
Ah, I did not look at the 1.3.0 file. So the above will help for all
released emacs versions, but will just not run for a non-recent master
of Emacs 28, get it.
I don't have a backtrace yet, but can provide one if it's helpful for
related questions. I guess I will just manually move xref-1.3.0 out of
the way until I can update to a newer Emacs master (which will then
include the coordinated xref/etags changes).
Yeah, the packaging story is not really robust yet. I only mentioned
"semantic versioning" as a general concept, but I am aware that the
package repositories and the dependency format are just not prepared to
make use of it anyway.
Thanks for your help!
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#51270: 28.0.50; xref core package 1.3.0 published, breaks etags
2021-10-18 21:12 ` Ingo Lohmar
@ 2021-10-18 21:40 ` Dmitry Gutov
2021-10-19 17:10 ` Ingo Lohmar
0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Gutov @ 2021-10-18 21:40 UTC (permalink / raw)
To: Ingo Lohmar, 51270
On 19.10.2021 00:12, Ingo Lohmar wrote:
> On Mon, Oct 18 2021 23:38 (+0300), Dmitry Gutov wrote:
>
>>> 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.
>
> I am using the feature/pgtk branch, which is currently based on an older
> master (roughly 3m ago) it seems.
Ah, that's what it is!
>> 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 "..."))))
>
> Ah, I did not look at the 1.3.0 file. So the above will help for all
> released emacs versions, but will just not run for a non-recent master
> of Emacs 28, get it.
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?
> I don't have a backtrace yet, but can provide one if it's helpful for
> related questions. I guess I will just manually move xref-1.3.0 out of
> the way until I can update to a newer Emacs master (which will then
> include the coordinated xref/etags changes).
Sounds good. And pgtk might as well do a merge from master (it won't be
in Emacs 28 apparently).
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#51270: 28.0.50; xref core package 1.3.0 published, breaks etags
2021-10-18 21:40 ` Dmitry Gutov
@ 2021-10-19 17:10 ` Ingo Lohmar
2021-10-19 22:05 ` Dmitry Gutov
0 siblings, 1 reply; 6+ messages in thread
From: Ingo Lohmar @ 2021-10-19 17:10 UTC (permalink / raw)
To: Dmitry Gutov, 51270
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)!
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#51270: 28.0.50; xref core package 1.3.0 published, breaks etags
2021-10-19 17:10 ` Ingo Lohmar
@ 2021-10-19 22:05 ` Dmitry Gutov
0 siblings, 0 replies; 6+ messages in thread
From: Dmitry Gutov @ 2021-10-19 22:05 UTC (permalink / raw)
To: Ingo Lohmar, 51270-done
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-10-19 22:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-18 10:13 bug#51270: 28.0.50; xref core package 1.3.0 published, breaks etags Ingo Lohmar
2021-10-18 20:38 ` Dmitry Gutov
2021-10-18 21:12 ` Ingo Lohmar
2021-10-18 21:40 ` Dmitry Gutov
2021-10-19 17:10 ` Ingo Lohmar
2021-10-19 22:05 ` Dmitry Gutov
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).