GNU bug report logs - #48015
28.0.50; ELPA package compilation fails

Previous Next

Package: emacs;

Reported by: Michael Albinus <michael.albinus <at> gmx.de>

Date: Sun, 25 Apr 2021 10:39:02 UTC

Severity: normal

Found in version 28.0.50

Full log


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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 48015 <at> debbugs.gnu.org
Subject: Re: bug#48015: 28.0.50; ELPA package compilation fails
Date: Mon, 26 Apr 2021 18:16:18 -0400
> Same here. Hitting C-g at the password prompt is not sufficient to
> trigger the error for package installation.
>
> Maybe you could use something else? "emacs -Q /ssh::" did the failing
> test.

Indeed, I can reproduce the problem now.  Basically you need
default-directory to be under Tramp's control.

The core problem that I see is the following:

- Emacs's tramp gets loaded
- We go to a Tramp-controlled default-directory
- We call `package--load-files-for-activation`
  - This starts by loading ~/.emacs.d/elpa/tramp-NN.MM/tramp-autoloads.el
    This calls `tramp-register-autoload-file-name-handlers`.
  - At this point, `package--load-files-for-activation` would like to
    continue by (re)loading the new Tramp files, such as `tramp-compat`
    and friends in the same order that they have been loaded
    (i.e. `tramp-compat.el` before `tramp.el`).
  - But before it gets a chance to do that, the file-name handlers
    call `tramp-autoload-file-name-handler` because of `default-directory`,
    which does (load "tramp" 'noerror 'nomessage), which loads the new
    `tramp.el` before we got a change to load the new `tramp-compat.el`,
    which then leads to an error when the new code in `tramp.el` calls
    a new function from `tramp-compat.el` (which happens to be
    `tramp-compat-thread-yield` AFAICT).

At this point, I'm not sure how best to fix the problem.
Maybe replacing (load "tramp" 'noerror 'nomessage) with
(require 'tramp nil t) is all it takes.
Or maybe a better option is to arrange the autoloads such that
`tramp-register-autoload-file-name-handlers` doesn't "unload/unregister" file
handlers that have already been loaded so that the directory that was
already under Tramp's control doesn't re-trigger a call to
`tramp-autoload-file-name-handler`?


        Stefan





This bug report was last modified 4 years and 131 days ago.

Previous Next


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