bug#48015: 28.0.50; ELPA package compilation fails

[Stefan Monnier]

> 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