bug#63260: 29.0.90; Regression installing/activating packages without autoloads

[Philip Kaludercic <philipk@posteo.net>]

[-- Attachment #1: Type: text/plain, Size: 2281 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Basil Contovounesios <contovob@tcd.ie>,  63260@debbugs.gnu.org,
>>   rpluim@gmail.com
>> Date: Sun, 07 May 2023 12:39:48 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > AFAIU, in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62734 I asked
>> > Philip what would happen in this case, and he replied that the changes
>> > he proposed did TRT in that case?  So what is different here?  Philip?
>> 
>> No, that appears to have been my mistake.  The issue is that
>> `loaddefs-generate' generates the autoload file while looping over all
>> definitions to autoload, but if there are no files, Basil is right that
>> nothing happens.  This is fine in general, but `loaddefs-generate' has
>> the extra task of modifying load-path (which has been the root of the
>> issue in bug#62734).  Perhaps it is best to revert the commit, and come
>> up with a alternative solution.  I have an idea, but I'll have to test
>> it again before I forget something like this.
>
> If we revert that commit, we will bring back bug#62734, which to me
> sounds like a similarly serious, perhaps even more serious, issue,
> don't you agree?  

My idea was that we could revert the commit, and then install a smaller
change, basically just replacing the condition

  (and (not defs) extra-data)

with

  (not defs)

but thinking about it for a bit, I noticed that you are right that this
would just re-introduce the same issue.

>                   So I think maybe we need to amend that commit with
> something that takes care of the particular situation reported here.
> Specifically, it seems we need to detect the situation where a package
> has no autoloads at all, and then produce the minimal autoloads file
> that such packages expect.

One hack might just be to check if `loaddefs-generate' has generated
anything at all or not, and if that is not the case to do so manually in
package.el.  The reason this doesn't seem nice, is that we'd have to
make the fact that `loaddefs-generate' does not generate a OUTPUT-FILE
if there is no file with autoloads explicit, and finding a justification
for that is difficult.  Alternatively, this could be done inside of
`loaddefs-generate'?  Something like


[-- Attachment #2: Type: text/plain, Size: 1021 bytes --]

diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el
index 2a46fb7a022..c23f21553d5 100644
--- a/lisp/emacs-lisp/loaddefs-gen.el
+++ b/lisp/emacs-lisp/loaddefs-gen.el
@@ -656,7 +656,17 @@ loaddefs-generate
             (write-region (point-min) (point-max) loaddefs-file nil 'silent)
             (byte-compile-info
              (file-relative-name loaddefs-file (car (ensure-list dir)))
-             t "GEN")))))))
+             t "GEN")))))
+
+    ;; HACK: If no file with autoloads were found, but EXTRA-DATA was
+    ;; passed, we still want to generate a file.
+    (unless (and extra-data (file-exists-p output-file))
+      (with-temp-buffer
+        (insert (loaddefs-generate--rubric output-file nil t))
+        (search-backward "\f")
+        (insert extra-data)
+        (ensure-empty-lines 1)
+        (write-region (point-min) (point-max) output-file nil 'silent)))))
 
 (defun loaddefs-generate--print-form (def)
   "Print DEF in a format that makes sense for version control."

[-- Attachment #3: Type: text/plain, Size: 23 bytes --]


-- 
Philip Kaludercic