From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#62734: Always fully rebuild autoloads in package-generate-autoloads Date: Fri, 28 Apr 2023 18:22:43 +0000 Message-ID: <87fs8jg93g.fsf@posteo.net> References: <87lej2oz14.fsf@le0.gs> <874jp0aw7h.fsf@posteo.net> <83pm7oqa7d.fsf@gnu.org> <87o7n7ga4x.fsf@posteo.net> <83o7n7ri64.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8302"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62734@debbugs.gnu.org, leo.gaskin@le0.gs To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 28 20:23:28 2023 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 1psSkh-0001se-2W for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 28 Apr 2023 20:23:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1psSkM-00016p-SK; Fri, 28 Apr 2023 14:23:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1psSkI-00016N-Oy for bug-gnu-emacs@gnu.org; Fri, 28 Apr 2023 14:23:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1psSkI-0001sb-B3 for bug-gnu-emacs@gnu.org; Fri, 28 Apr 2023 14:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1psSkH-0004FN-O0 for bug-gnu-emacs@gnu.org; Fri, 28 Apr 2023 14:23:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Apr 2023 18:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62734 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 62734-submit@debbugs.gnu.org id=B62734.168270614616267 (code B ref 62734); Fri, 28 Apr 2023 18:23:01 +0000 Original-Received: (at 62734) by debbugs.gnu.org; 28 Apr 2023 18:22:26 +0000 Original-Received: from localhost ([127.0.0.1]:34446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psSje-0004EG-OG for submit@debbugs.gnu.org; Fri, 28 Apr 2023 14:22:26 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:36473) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psSjZ-0004Dy-OS for 62734@debbugs.gnu.org; Fri, 28 Apr 2023 14:22:21 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A495524033A for <62734@debbugs.gnu.org>; Fri, 28 Apr 2023 20:22:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682706131; bh=PMmJa0tMblbFdzrcGYBm6HqvapFSSmCll2+FTNbPbgg=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=fhHRlG+0w1NLGKa6bQ1NFw8H1568IGI3rW7MF2TCB47TDd/vkZYuTjakxfoYqWywF jmSTFOoDplD7IQajEplg6imDW+yTGCI/FQDfR7U8qCiUUDW9XJYzlAiZPxdiTdI0JW mpCsG4LB/HxQhCNgjhDV8DCs3a2S+Khe1tDs9Ftm6NXPzJ9vHT+jDc94gjjQW58QC4 AjvzVdyNq10QbbNbsteQiTXBGYec0pRtcLFww59GrYy7X35jQrl+3RCte8+0Mw9DUi MXUie5/VofZbml46VzcfdAZT+nJOi+Suwh3CbpIhWZ53KTijBKQsARKUfQqsJwby25 MBtfARFUBGulA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q7LYH1b1Dz6txV; Fri, 28 Apr 2023 20:22:11 +0200 (CEST) In-Reply-To: <83o7n7ri64.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 28 Apr 2023 21:11:15 +0300") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:260786 Archived-At: Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: leo.gaskin@le0.gs, 62734@debbugs.gnu.org >> Date: Fri, 28 Apr 2023 18:00:14 +0000 >> >> > I don't understand the original problem (what does package-vc.el have >> > to do with rebuilding local packages? >> >> When package updates a package, it deletes the old code and downloads >> the new stuff. package-vc keeps the same code, but pulls the new >> revisions, so it is necessary to re-generate the loaddef files for the >> same files. > > What is meant by "building the package"? Is it just compiling the > Lisp files? >From `package-vc-rebuild': Rebuilding an installation means scraping for new autoload cookies, re-compiling Emacs Lisp files, building and installing any documentation, downloading any missing dependencies. >> > and why is a newly generated >> > loaddefs file incomplete or empty?), and I certainly don't think I >> > understand the effects of this change on the other usage scenarios. >> >> >From what I get, this is an issue in `loaddefs-generate'. If we do not >> force updating the file, and >> >> --8<---------------cut here---------------start------------->8--- >> (time-less-p output-time >> (file-attribute-modification-time >> (file-attributes file))) >> --8<---------------cut here---------------end--------------->8--- >> >> does not hold > > Why would it not hold? Updating from VCS should update the timestamp > of the updated files. I don't think this necessarily holds if there were no changes affecting a file. >> Another idea is just to get rid of this faulty optimisation. From my >> tests this would also resolve the bug. > > I don't yet understand what optimization is that, but getting rid of > it should not alter what the code does for the loaddefs files inside > the Emacs tree, because there it does work, and I don't want to touch > that. Are you sure it does work? I am currently having difficulties understanding how the `with-temp-buffer' code snippet I quoted above /can/ do the right thing. I am under the impression that wherever `loaddefs-generate' is invoked, it avoids this execution path, either by passing no EXTRA-DATA or by making sure that at least some autoload is collected. >> > Why would we want to unconditionally rebuild all the loaddefs files >> > every time package-generate-autoloads is invoked? OTOH, that function >> > is not really documented, so maybe I don't understand what is it >> > supposed to do and in which conditions. >> >> The matter was that for regular packages, it was already rebuilt every >> time `loaddefs-generate' was invoked, since there were never any old >> loaddefs to update. > > This is only true as long as updating a package removes the previous > version entirely, including the generated files. This is not > something I'd like us to assume in every corner of package.el, since > some day it can become false. Ok, fair point considering that package-vc currently does this.