bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#63757: 29.0.91 order of package paths changed: random old versions o


From: Philip Kaludercic
Subject: bug#63757: 29.0.91 order of package paths changed: random old versions of packages in load-path
Date: Sun, 04 Jun 2023 12:32:17 +0000

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: artscan@list.ru,  monnier@iro.umontreal.ca,  63757@debbugs.gnu.org
>> Date: Sun, 04 Jun 2023 12:12:16 +0000
>> 
>> I'm sorry, that was the wrong patch -.-
>> 
>> diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
>> index de5108430aa..fdc09a939be 100644
>> --- a/lisp/emacs-lisp/package.el
>> +++ b/lisp/emacs-lisp/package.el
>> @@ -739,7 +739,7 @@ package-load-all-descriptors
>>  updates `package-alist'."
>>    (dolist (dir (cons package-user-dir package-directory-list))
>>      (when (file-directory-p dir)
>> -      (dolist (pkg-dir (directory-files dir t "\\`[^.]" t))
>> +      (dolist (pkg-dir (directory-files dir t "\\`[^.]"))
>>          (when (file-directory-p pkg-dir)
>>            (package-load-descriptor pkg-dir))))))
>>  
>> (I attached the *vc-diff* buffer, but before sending the message I
>> invoked vc-diff again which modified the buffer contents.  Should have
>> just copied the diff manually...)
>
> Thanks, now it at least makes sense.
>
> But why does it matter whether the package directory names are sorted
> or not?  Is sorting package versions the same as sorting the names of
> their directories?

No, because directories are sorted by their names and by that metric,
"foo-10" is less than "foo-9".  But since package archives like MELPA
use ISO 8601-like release-dates as version numbers, the order "works".
If we disable sorting, the files returned in any order the operating
system might have arbitrary stored the directory entries in which might
even change depending on the file system.  So at the very least we can
argue that while sorting does not solve the issue, it provides a quick
hack to prevent sudden breakage from Emacs 28 to Emacs 29, due to users
relying on this kind of behaviour.  A proper solution, that takes
version numbers into account should be prepared on the master branch.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]