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: Wed, 25 Sep 2024 20:11:20 +0000 Message-ID: <8734lnsdcn.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> <878qvjaep6.fsf@posteo.net> <87cykvwixn.fsf@gmail.com> <87ikukrl77.fsf@posteo.net> <871q17dasa.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="724"; 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 Wed Sep 25 22:12:20 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 1stYN1-000Ac3-1S for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Sep 2024 22:12:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1stYMK-00014Z-6P; Wed, 25 Sep 2024 16:11:36 -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 1stYMD-000146-68 for emacs-devel@gnu.org; Wed, 25 Sep 2024 16:11:30 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1stYMA-0002jQ-3B for emacs-devel@gnu.org; Wed, 25 Sep 2024 16:11:28 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A845E240103 for ; Wed, 25 Sep 2024 22:11:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1727295082; bh=26uGVA/kTOo5ztB59SpEqk17KjwlNVkkSpKg0wihIr0=; h=From:To:Cc:Subject:Autocrypt:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=kOWfXW9NMn3HfNGjlYaM/csearOLCcjQqWEYr9Yy/7rgOWojt0xjSfkz2/0E8kAf0 zaU5J2wjDGA0VX9vaFsX6POQAmsEPau3qqhNxTxBUeQrZZBEj6j4XJj7pfTFQe4zUz UaYUJdiRavssBr6VfofGQ3926c00MtNzcvv7BD+u8/MwrdPx7AH49SxaScnhrOPw4y N9x5cUyFEDkmVKuyqprm8p7Tv5Uidv3aMl9FZQQ9/+B5sRDi1ny7pEfeTZGoMqhZtt t10itwSWqmk2N1JZjmsbFi1ad/IFkxtmD4ra4pnNQ0jVwyGpyzpJdl5cO6LM6R6LJg XavbOoeGyJFmA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4XDSY53hZtz9rxD; Wed, 25 Sep 2024 22:11:21 +0200 (CEST) In-Reply-To: <871q17dasa.fsf@gmail.com> (Suhail Singh's message of "Wed, 25 Sep 2024 11:15:49 -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=philipk@posteo.net; url="https://keys.openpgp.org/vks/v1/by-email/philipk@posteo.net"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:324087 Archived-At: Suhail Singh writes: > Philip Kaludercic 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? IIRC the local package you have installed, the package on NonGNU ELPA, the package on MELPA Stable and the package on MELPA Unstable. > 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. Yeah, that was my intention as well. > 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. NON-UNIQUE COMMIT seems more vague to me? >> 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). We don't track multiple version numbers by default, but only the package as announced by a package archive. And VC packages seem like a bit of an headache in this case, as >> 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. I could have checked that as well myself, basically I just had to load https://melpa.org/packages/archive-contents and then one sees that each package description has a :commit entry. >> + (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. Right, I'll try to test this myself before sending you more patches ^^ >> 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 ) to > begin with? Alternatively, if the elpa-admin variant is considered the > canonical version, why doesn't the link from > point to > > instead? No reason really, I'll try to update it soon. > 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. -- Philip Kaludercic on siskin