Re: Reconsider defaults for use-package-vc-prefer-newest

[Philip Kaludercic]

Suhail Singh <suhailsingh247@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>>>> I wonder if indicating a "commit mismatch" for remote packages might
>>>> be interesting (we explicitly don't want this for local packages,
>>>> e.g. packages installed via package-vc).
>>>
>>> Depending on the logic of "commit mismatch" detection, that may be
>>> sufficient.  Could you describe what you had in mind?
>>
>> In your case/the case of julia-mode, something like
>>
>>   Other versions: 1.2.3 (melpa-stable, COMMIT MISMATCH).
>>
>> with a help annotation.
>
> Yes, something like that would have worked.  Thanks in advance, if you
> do implement something of that nature.  It would be useful.

Can you test if this works:

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 7cae8d68bc0..d27b6b73eee 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -2961,23 +2961,26 @@ describe-package-1
                              (cdr (assq name package-archive-contents))
                              (let ((bi (assq name package--builtins)))
                                (if bi (list (package--from-builtin bi))))))
-           (other-pkgs (delete desc all-pkgs)))
+           (other-pkgs (delete desc all-pkgs))
+           (commit (alist-get :commit (package-desc-extras desc))))
       (when other-pkgs
         (package--print-help-section "Other versions"
           (mapconcat (lambda (opkg)
                        (let* ((ov (package-desc-version opkg))
                               (dir (package-desc-dir opkg))
                               (from (or (package-desc-archive opkg)
-                                        (if (stringp dir) "installed" dir))))
+                                        (if (stringp dir) "installed" dir)))
+                              (ocommit (alist-get :commit (package-desc-extras 
opkg))))
                          (if (not ov) (format "%s" from)
-                           (format "%s (%s)"
+                           (format "%s (%s%s)"
                                    (make-text-button (package-version-join ov) 
nil
                                                      'font-lock-face 'link
                                                      'follow-link t
                                                      'action
                                                      (lambda (_button)
                                                        (describe-package 
opkg)))
-                                   from))))
+                                   from
+                                   (if (equal ocommit commit) "" ", COMMIT 
MISMATCH!")))))
                      other-pkgs ", ")
           ".")))
 

>>>> Could you perhaps elaborate on why you consider this to be a bug?
>>>
>>> To be clear I meant that it's a bug in the remote package.
>>
>> Perhaps I am being pedantic, but this sounds like a mistake, not a /bug/
>> in the code itself.
>
> I meant that I considered it a software defect in the packaging process.
> It might have been more accurate to term it a bug in the remote
> package's packaging process.  In any case, the implication wasn't that
> it was a bug in the remote package's source code.  I hope it's clearer
> now.

No worries, I think we both understand what we mean.

>>> Specifically, in the case of julia-mode, it was a bug for it to have
>>> introduced the 0.4 package header in a commit that was different from
>>> the one that was tagged as 0.4.
>>
>> Do you know which of the two is correct?  In cases like these, it sounds
>> like one should contact the maintainers to remind them that they
>> shouldn't repeat the same issue in the future.
>
> Given that the change that was added between the commit that updated the
> package header and the commit that corresponded to the git tag was a
> fairly important bug-fix, I believe the intended revision (for 0.4) was
> the one corresponding to the git tag (i.e., the more recent commit and
> the one available via melpa-stable).
>
> In general, for packages with a git repository that have a presence
> outside of GNU and NonGNU ELPA, I believe the version corresponding to
> the "git tag" to be more closely aligned with the maintainer's intent.
>
> That being said, however, based on a recent exchange, the recommended
> version that the maintainer of julia-mode wishes users download is the
> "rolling release" equivalent from melpa.  I believe it is for this
> reason that they have not made a tagged release in the last four years.
> Quoting below the maintainer's response on the issue ([1]) where I
> brought this matter to their attention:
>
> #+begin_quote
>   Since we do not make stable releases (effectively, it is just rolling on
>   `master`, I think we should just clarify that users should use `melpa`, and 
> if
>   possible expunge the package from `melpa-stable` etc.
> #+end_quote
>
> [1]: 
> <https://github.com/JuliaEditorSupport/julia-emacs/issues/212#issuecomment-2328150198>

If that is so, then we can also mark the ELPA package as using a
rolling-release model, i.e. the build server prepares a new tarball
every time is synchronises new commits.

-- 
        Philip Kaludercic on siskin