From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#48015: 28.0.50; ELPA package compilation fails Date: Tue, 27 Apr 2021 09:47:25 -0400 Message-ID: References: <875z0amyxo.fsf@gmx.de> <87wnsql1ih.fsf@gmx.de> <87v988c4qp.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36837"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 48015@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 27 15:49:35 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lbO5m-0009JY-OL for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 27 Apr 2021 15:49:34 +0200 Original-Received: from localhost ([::1]:42568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lbO5l-0002fh-S6 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 27 Apr 2021 09:49:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58576) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbO4I-0001nd-5I for bug-gnu-emacs@gnu.org; Tue, 27 Apr 2021 09:48:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36797) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lbO4H-0004Ww-TU for bug-gnu-emacs@gnu.org; Tue, 27 Apr 2021 09:48:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lbO4H-0006fG-NB for bug-gnu-emacs@gnu.org; Tue, 27 Apr 2021 09:48:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 27 Apr 2021 13:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48015 X-GNU-PR-Package: emacs Original-Received: via spool by 48015-submit@debbugs.gnu.org id=B48015.161953125725579 (code B ref 48015); Tue, 27 Apr 2021 13:48:01 +0000 Original-Received: (at 48015) by debbugs.gnu.org; 27 Apr 2021 13:47:37 +0000 Original-Received: from localhost ([127.0.0.1]:48342 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbO3s-0006eT-Qm for submit@debbugs.gnu.org; Tue, 27 Apr 2021 09:47:37 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:6636) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbO3q-0006e0-L6 for 48015@debbugs.gnu.org; Tue, 27 Apr 2021 09:47:35 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 02E2280931; Tue, 27 Apr 2021 09:47:29 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 690DC8083B; Tue, 27 Apr 2021 09:47:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1619531247; bh=nGc4JVkr68OdStcQAGzZEKEt1evJFyxB8hAGYf+Xzjw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=heIkyxf4lG5NTKe/i5qHi3RAhHZg0Fkgats0o+2tszTCKSirk81/YSqXqA5+NGajQ 98mehrWwXTaGQp7yGU9NqsHUDfwzmuadqpRiDsA0skxnE5Zn8KR3JVwibMYyfuUcRj TAl25X/icQQk1DV3WR5dm68sbQTHhpl7ruUuSFRWj1uNDySEgarwr6iUQbx1zBphRb +uBuNbTlHQ9U0yJP89Ueex9cOZiG0TNjl30jb7ZDzD+41i5jQEsOJmex4vGIXiwrr0 YuzD+qTTiDY13MNSw6PaiEy1lhDuAlbFxgShP1hHlT/srhvS37GEk8G7q9+A7gV4f3 rpQHsYvNW9eRA== Original-Received: from alfajor (unknown [157.52.10.47]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 10DEC120312; Tue, 27 Apr 2021 09:47:27 -0400 (EDT) In-Reply-To: <87v988c4qp.fsf@gmx.de> (Michael Albinus's message of "Tue, 27 Apr 2021 14:05:18 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:205016 Archived-At: >> 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