all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 48015@debbugs.gnu.org
Subject: bug#48015: 28.0.50; ELPA package compilation fails
Date: Tue, 27 Apr 2021 09:47:25 -0400	[thread overview]
Message-ID: <jwvpmyfn9f3.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87v988c4qp.fsf@gmx.de> (Michael Albinus's message of "Tue, 27 Apr 2021 14:05:18 +0200")

>> 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`?
>
> What I don't understand: when (load "tramp" 'noerror 'nomessage) is
> called, default-directory is already local due to a let-binding.

That's fine, this load functions properly.  The problem is elsewhere:
- loading the new `tramp.el` works properly but results in a broken
  setup because it will not load the new `tramp-compat.el`
  because that feature is already provided.  So you end up with a new`
  tramp.el` calling functions it expects to be provided by the new
  `tramp-compat.el`.
- the Tramp default-directory is not active during the load, but it is
  active right before it (it is the trigger that causes the load, actually)
  and it is active right after it (before package.el gets to reload
  `tramp-compat.el`) and that's when the new code from `tramp.el`
  signals an error because of the missing function from the new
  `tramp-compat.el`.

> Anyway, even if the compilation runs through in case of a local
> default-directory, the resulting *.elc files have errors.
>
> I have quit Emacs (from the first recipe), and then I have started
>
>     emacs -Q -L ~/.emacs.d/elpa/tramp-2.5.0.3/ /ssh::
>
> There are further errors, which are related to a wrong
> tramp-compat.el. Only my new command tramp-recompile-elpa fixes this.

I suspect this is the result of the `find-library-name` problem I fixed
yesterday on `master` (which causes `package.el` not to load the new
files to override the old ones before compiling the new files).

You can circumvent it by loading `find-func` before doing the
`package-install`.  I'm not sure how the GNU ELPA package of Tramp can
protect itself from this bug yet (beside `tramp-recompile-elpa`, of
course).

BTW, maybe one option to circumvent both problems is to replace

    (load "tramp" 'noerror 'nomessage)

with

    (load "tramp-compat" 'noerror 'nomessage)
    (load "tramp" 'noerror 'nomessage)

?


-- Stefan






  reply	other threads:[~2021-04-27 13:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-25 10:38 bug#48015: 28.0.50; ELPA package compilation fails Michael Albinus
2021-04-25 16:24 ` Stefan Monnier
2021-04-25 17:25   ` Michael Albinus
2021-04-26 22:16     ` Stefan Monnier
2021-04-27 12:05       ` Michael Albinus
2021-04-27 13:47         ` Stefan Monnier [this message]
2021-04-27 18:58           ` Stefan Monnier
2021-04-27 19:13             ` Michael Albinus
2021-04-28 14:22             ` Michael Albinus
2021-04-28 15:32               ` Stefan Monnier
2021-04-28 17:48                 ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvpmyfn9f3.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=48015@debbugs.gnu.org \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.