all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Suhail Singh <suhailsingh247@gmail.com>
To: Philip Kaludercic <philipk@posteo.net>
Cc: "Suhail Singh" <suhailsingh247@gmail.com>,
	"Martin Edström" <meedstrom@runbox.eu>,
	emacs-devel <emacs-devel@gnu.org>,
	"Tony Zorman" <tonyzorman@mailbox.org>
Subject: Re: Reconsider defaults for use-package-vc-prefer-newest
Date: Wed, 25 Sep 2024 11:15:49 -0400	[thread overview]
Message-ID: <871q17dasa.fsf@gmail.com> (raw)
In-Reply-To: <87ikukrl77.fsf@posteo.net> (Philip Kaludercic's message of "Wed,  25 Sep 2024 12:07:08 +0000")

Philip Kaludercic <philipk@posteo.net> writes:

> The idea is to add a "COMMIT MISMATCH" warning whenever we detect that
> two packages have different commits.

Which are the two packages being considered?

From my perspective, the following is the desired behaviour: whenever
package.el has evidence that the same purported package version is being
served via different commits in the various remote archives (that the
user has enabled) the user is made aware.  If the package versions
aren't the same, then no "COMMIT MISMATCH" should be shown.

I.e., the situation of interest is when versions match, but commits
don't.  If it helps, "NON-UNIQUE COMMIT" might be more accurate, but I
don't have a strong opinion on the wording.

> What this doesn't do yet is eliminate false positives, such as
> different commits between a local version of a package and a remote
> version.  I guess we are only interested in differences between remote
> packages, right?

If the package is a local :vc checkout, I don't have strong opinions on
whether it is considered or ignored.  If the package is an installed
version (via package-install), then it should be compared against any
other version that has the same version number (i.e., in the same manner
as a remote package would be compared).

> Does MELPA annotate their packages with commits?

Both MELPA and MELPA Stable seem to.  I am basing this on the assumption
that the result of button-describe comes from the archive in question.
If there is a better way to confirm, please do let me know.

> +                                   (if (and (not (package-desc-dir opkg))
> +                                            (equal ocommit commit))
> +                                       "" ", COMMIT MISMATCH!")))))

If (package-desc-dir opkg) evaluates to non-nil, then the above
evaluates to ", COMMIT MISMATCH!" which seems incorrect.

> It is documented on the elpa-admin branch:
>
> https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/README?h=elpa-admin&id=9bd65395f1d4875915731ddbdd73a471f10d7794#n215

Thanks for sharing the reference, but why is this not in the default
branch (which is the only one linked from <https://elpa.gnu.org/>) to
begin with?  Alternatively, if the elpa-admin variant is considered the
canonical version, why doesn't the link from <https://elpa.gnu.org/>
point to
<https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README?h=elpa-admin>
instead?

The comment at the top of the file states that the two versions "differ
slightly".  However, differences in the documentation of supported
options (regardless of whether or not their use is encouraged) is not
what I would consider a "slight" difference.

> That being said, I still think that this is a feature that we would want
> to advise package maintainers not to use.

Agreed.

-- 
Suhail



  reply	other threads:[~2024-09-25 15:15 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-14 12:09 Reconsider defaults for use-package-vc-prefer-newest Martin Edström
2024-09-19 11:49 ` Philip Kaludercic
2024-09-19 18:50   ` Suhail Singh
2024-09-19 20:11     ` Philip Kaludercic
2024-09-19 20:31       ` Philip Kaludercic
2024-09-20  6:15         ` Eli Zaretskii
2024-09-20 15:14           ` Philip Kaludercic
2024-09-20 15:45             ` Eli Zaretskii
2024-09-20 16:56               ` Philip Kaludercic
2024-09-20 17:37                 ` Eli Zaretskii
2024-09-20 20:43               ` Philip Kaludercic
2024-09-21  7:14                 ` Eli Zaretskii
2024-09-21 14:31                   ` Philip Kaludercic
2024-09-21 15:18                     ` Eli Zaretskii
2024-09-21 15:43                       ` Philip Kaludercic
2024-09-19 21:02       ` Suhail Singh
2024-09-20 20:34         ` Philip Kaludercic
2024-09-20 23:38           ` Suhail Singh
2024-09-21  7:06             ` chad
2024-09-21 14:27               ` Suhail Singh
2024-09-21 15:59             ` Philip Kaludercic
2024-09-21 19:04               ` Suhail Singh
2024-09-22 15:30                 ` Philip Kaludercic
2024-09-22 20:08                   ` Suhail Singh
2024-09-25 12:06                     ` Suhail Singh
2024-09-25 13:15                       ` Philip Kaludercic
2024-09-25 12:07                     ` Philip Kaludercic
2024-09-25 15:15                       ` Suhail Singh [this message]
2024-09-25 20:11                         ` Philip Kaludercic
2024-09-25 20:48                           ` Suhail Singh
2024-09-29  2:13                           ` Richard Stallman
2024-09-29  7:25                             ` Philip Kaludercic
2024-09-29 13:55                               ` Suhail Singh
2024-09-26 23:23                     ` Charles Choi
2024-09-27  0:17                       ` Adam Porter
2024-09-27  0:33                       ` Suhail Singh
2024-09-27  6:46                       ` Eli Zaretskii
2024-09-29 14:22                         ` Stefan Kangas
2024-09-29 14:35                           ` Eli Zaretskii
2024-10-11 18:54                         ` Suhail Singh
2024-10-12  5:46                           ` Eli Zaretskii
2024-09-20  4:57   ` Tony Zorman
2024-09-20 19:37     ` Martin Edström
2024-09-20 21:05       ` Philip Kaludercic
2024-09-21 14:44     ` Philip Kaludercic
2024-09-21 14:58       ` Tony Zorman
2024-09-21 15:10       ` Suhail Singh
2024-09-21 16:09         ` Philip Kaludercic
  -- strict thread matches above, loose matches on Subject: below --
2024-09-15 17:38 Martin Edström
2024-09-15 18:24 ` Eli Zaretskii
2024-09-15 19:46   ` Martin Edstrom
2024-09-16 11:34     ` Eli Zaretskii
2024-09-16 15:24       ` Martin Edström
2024-09-16 16:15       ` Martin Edström
2024-09-16 17:57         ` Eli Zaretskii
2024-09-18 14:30           ` Martin Edström
2024-09-15 19:52 Martin Edström
2024-09-15 20:41 ` chad
2024-09-15 21:09   ` Martin Edstrom
2024-09-15 22:12     ` chad
2024-09-15 23:51       ` Martin Edstrom
2024-09-16 11:50     ` Eli Zaretskii
2024-09-16 16:46       ` Martin Edström
2024-09-16 18:10         ` Eli Zaretskii
2024-09-16 20:16       ` Suhail Singh
2024-09-17 11:44         ` Eli Zaretskii
2024-09-19  3:38           ` Suhail Singh
2024-09-19  6:28             ` Eli Zaretskii
2024-09-19 12:08               ` Suhail Singh
2024-09-19 12:39                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871q17dasa.fsf@gmail.com \
    --to=suhailsingh247@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=meedstrom@runbox.eu \
    --cc=philipk@posteo.net \
    --cc=tonyzorman@mailbox.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.