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: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VACS Date: Tue, 01 Nov 2022 18:27:55 +0000 Message-ID: <87iljyedhw.fsf_-_@posteo.net> References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <20220214140020.04438C00891@vcs2.savannah.gnu.org> <87bkqmqpvb.fsf@posteo.net> <87edv96q4j.fsf@posteo.net> <83tu455a5s.fsf@gnu.org> <87a65v2ytp.fsf@posteo.net> <834jw33rmx.fsf@gnu.org> <87pmer0xtz.fsf@posteo.net> <83wn8z2aze.fsf@gnu.org> <878rle1i0k.fsf@posteo.net> <87ilkelc10.fsf@posteo.net> <878rl6syg8.fsf@posteo.net> <87zgdjqcu0.fsf@posteo.net> <87pmeev40u.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39357"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 01 19:28:31 2022 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 1opvzz-000A1o-Bg for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Nov 2022 19:28:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opvza-0004x8-Q3; Tue, 01 Nov 2022 14:28:07 -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 1opvzU-0004u5-9w for emacs-devel@gnu.org; Tue, 01 Nov 2022 14:28:00 -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 1opvzS-0006qY-1A for emacs-devel@gnu.org; Tue, 01 Nov 2022 14:28:00 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 5D34324010D for ; Tue, 1 Nov 2022 19:27:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667327276; bh=opFvLivoPecTx0rmSiZtPWWzqnZIKoSxHjrHLDlPyhU=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=JDQkC8zTwZeNeZxX71E0KItPdpyFn5G67nY0KqmIZIcbDN9QEAJ2sIAOwTdo34Go2 MPkpBEaBKIFIqaUE4rGX49nre678uKwbtPWVzTlutcIBq+G6GqQULyBZfqAg07rR1b DXAWPJao5657y5bl4iA3zMjGqC0YT0hqV1cRgHVU/Fp+M++bp0Y4CcTnjQsf+Foadp 0m1hLgXo3DshXbww3DyPsERBe6b6BVYQDuWbeOf4pQH4ugNldtZ3YUKe24RXOgJdGH vVPQy5YzCPjI6FVNGMl3wn1E+bF2WTUwi7/SEavMZIlNV/+D7sdrpvAlKNc4Vyaic6 3BnOeCvtMOaJg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N1z636yt3z6tnC; Tue, 1 Nov 2022 19:27:55 +0100 (CET) In-Reply-To: (Richard Stallman's message of "Tue, 01 Nov 2022 12:46:13 -0400") Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB 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_H2=-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: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298966 Archived-At: Richard Stallman writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > I have pushed a commit to feature/package+vc that will use the release > > revision (if it is known) when `package-vc-install' is invoked with a > > prefix argument. > > It is good to offer both options. However, there may be a bug in this > way of doing it. > > The words "the release revision" are somewhat terse and I am not > entirely sure what they mean. My guess is they mean "the revision in > the upstream repo that corresponds to the released code in ELPA." Is > that correct? Yes, that is correct. > In the usual case, the released code in ELPA does correspond to some > revision in the upstream repo. Therefore, assuming the release > revision "is known", this implementation will find the right code. No, the revision used to create a release is always > However, in unusual cases the code in ELPA includes changes that did > not come from the upstream repo, and may not be present there. This > feature needs to DTRT in those cases too. Ah, now I understand where you are coming from. As I said in my previous message, if this is the case and we have a diverged package, we can always point to elpa.git/nongnu.git. package-vc.el uses a new file added to {GNU,NonGNU} ELPA that you can find here https://elpa.gnu.org/packages/elpa-packages.eld https://elpa.nongnu.org/nongnu/elpa-packages.eld These consist of package specifications like ("ace-window" :url "https://github.com/abo-abo/ace-window" :auto-sync t) for upstream repositories, or ("adjust-parens" :url "https://git.sv.gnu.org/git/emacs/elpa.git" :branch "externals/adjust-parens") for repositories that are to be checked out directly from elpa.git. > To check out the latest revision in the upstream repo is certainly wrong, > and it could cause serious confusion. The command should never do > that, not even as a fallback. Fallback from what? If you think the ELPA mirror ought to always be used, then why even bother with pointing to the upstream repository? If anyone needs the upstream repository, they can always add it themselves. This would mean that the first package specification I have above would just become ("ace-window" :url "https://git.sv.gnu.org/git/emacs/elpa.git" :branch "externals/ace-window") The only arguments I see are to reduce the load on Savannah and to avoid the update-lag for auto-synchronised packages between the point in time when a commit is pushed to the upstream repository and the point it is mirrored. > What other behavior would be a better fallback? > What is TRT in these cases? > I see two reasonable possibilities: > > 1. To signal an error and do nothing. > > 2. To check out the current release version from the ELPA repo (NOT > the upstream repo). > > I think #2 is better, but #1 at least avoids confusion. I believe we are talking about diverged packages, right? Just to clarify my previous point, this ought to be detectable on the server side of things, in which case the mirror is used -- unless we always decide to use the mirror. There is no need for special handling in package-vc.el -- in fact the entire point is unrelated to the branch and any issue blocking the merging into master. > In what situations is the release revision not known? > We should think about what is TRT in those cases too. > First, what cases are they? The release revision is the most recent release that bumped the "Version" header, as described in (elisp) Simple Packages. If there is no such header, the package is not released onto ELPA, hence it wouldn't appear in the package archive to begin with. This is only an issue for unreleased packages, in which case we cannot state what the release revision is supposed to be in the first place. This is handled by the following code right now: (if-let ((release-rev (package-vc-release-rev pkg-DECs))) (vc-retrieve-tag pkg-dir release-rev) (message "No release revision was found, continuing...")) I fear we might disagree as to how fatal or not this case is. I think it is better to complete the installation at all instead of aborting it, which is why I just emit a message and continue on. But I do recognise the point that if someone wants the revision used to release a package, then we should take that request seriously.