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.devel Subject: Re: Reconsider defaults for use-package-vc-prefer-newest Date: Sun, 22 Sep 2024 15:30:29 +0000 Message-ID: <878qvjaep6.fsf@posteo.net> References: <87wmj7dftf.fsf@posteo.net> <87setvxyt6.fsf@gmail.com> <87jzf7o13b.fsf@posteo.net> <87msk3jr0u.fsf@gmail.com> <87setum5do.fsf@posteo.net> <87msk1520e.fsf@gmail.com> <87settknf1.fsf@posteo.net> <87tte8akwa.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16178"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Martin =?utf-8?Q?Edstr=C3=B6m?= , "emacs-devel" , Tony Zorman To: Suhail Singh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 22 17:31:35 2024 Return-path: Envelope-to: ged-emacs-devel@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 1ssOYg-0003zu-84 for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Sep 2024 17:31:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ssOXs-0007Jh-59; Sun, 22 Sep 2024 11:30:44 -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 1ssOXl-0007JL-Uh for emacs-devel@gnu.org; Sun, 22 Sep 2024 11:30:42 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ssOXj-00058S-64 for emacs-devel@gnu.org; Sun, 22 Sep 2024 11:30:37 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 445FB240028 for ; Sun, 22 Sep 2024 17:30:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1727019031; bh=H9wuqm6MrV1guATeNRtBiMZ2EpNrQ4srEI+IEYqE7zU=; h=From:To:Cc:Subject:Autocrypt:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=lpKkolBFtiafum8ECEYwoTfv6xas2kDJakh60xH7eB/opfO1Rvm0xpWmxKcaWRjGr DbLli9CERpj9o3zVzxdMBysDSToNNcuuqIVOdLLjf+aIExHJtnW5p3MIJoQZP57F72 np7Xp0TQ+/4e/L0AVlezohBMPbaNwE6xEDqoWKKWccJS0IIBsNYjo84XVd5VNeyiav MeEIO8u04JGVqFNnYbeT4pUWbxk+egdmqvCErI4USXSFpBez1anqOmZNPaPWiwm+hH NVwk250CJIZX3czi5YTsoPGjqaJKYlsWGWIjOrpD96Q2ljJvlh9VaWY8MY3MZRY297 qAfSwcpsIUygA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4XBVSP6vPhz9rxB; Sun, 22 Sep 2024 17:30:29 +0200 (CEST) In-Reply-To: <87tte8akwa.fsf@gmail.com> (Suhail Singh's message of "Sat, 21 Sep 2024 15:04:21 -0400") 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 OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:323926 Archived-At: --=-=-= Content-Type: text/plain Suhail Singh writes: > Philip Kaludercic 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: --=-=-= Content-Type: text/plain Content-Disposition: inline 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 ", ") "."))) --=-=-= Content-Type: text/plain >>>> 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]: 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 --=-=-=--