GNU bug report logs - #51270
28.0.50; xref core package 1.3.0 published, breaks etags

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51270 in the body.
You can then email your comments to 51270 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ingo Lohmar <ingo.lohmar <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; xref core package 1.3.0 published, breaks etags
Date: Mon, 18 Oct 2021 10:13:04 +0000

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 #8 received at 51270 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Ingo Lohmar <ingo.lohmar <at> posteo.net>, 51270 <at> debbugs.gnu.org
Subject: Re: bug#51270: 28.0.50; xref core package 1.3.0 published, breaks
 etags
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.

Message #11 received at 51270 <at> debbugs.gnu.org (full text, mbox):

From: Ingo Lohmar <ingo.lohmar <at> posteo.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>, 51270 <at> debbugs.gnu.org
Subject: Re: bug#51270: 28.0.50; xref core package 1.3.0 published, breaks
 etags
Date: Mon, 18 Oct 2021 21:12:37 +0000

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!

Message #14 received at 51270 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Ingo Lohmar <ingo.lohmar <at> posteo.net>, 51270 <at> debbugs.gnu.org
Subject: Re: bug#51270: 28.0.50; xref core package 1.3.0 published, breaks
 etags
Date: Tue, 19 Oct 2021 00:40:44 +0300

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).

Message #17 received at 51270 <at> debbugs.gnu.org (full text, mbox):

From: Ingo Lohmar <ingo.lohmar <at> posteo.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>, 51270 <at> debbugs.gnu.org
Subject: Re: bug#51270: 28.0.50; xref core package 1.3.0 published, breaks
 etags
Date: Tue, 19 Oct 2021 17:10:46 +0000

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)!

Message #22 received at 51270-done <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Ingo Lohmar <ingo.lohmar <at> posteo.net>, 51270-done <at> debbugs.gnu.org
Subject: Re: bug#51270: 28.0.50; xref core package 1.3.0 published, breaks
 etags
Date: Wed, 20 Oct 2021 01:05:45 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.