From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS Date: Tue, 01 Nov 2022 12:46:13 -0400 Message-ID: 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> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13365"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 01 18:13:52 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 1opupj-0003Hz-Bx for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Nov 2022 18:13:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opuP4-000078-U9; Tue, 01 Nov 2022 12:46:18 -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 1opuP3-00006s-8V for emacs-devel@gnu.org; Tue, 01 Nov 2022 12:46:17 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1opuP1-0000Bp-6K; Tue, 01 Nov 2022 12:46:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=NBn1rZXUVQMkJQh8LScZA5hLv2i4y1KX1MWlQMgFnR0=; b=AxIlR7MpoRsN iotuQD2/38ye8jzK4ps8vYOQHzn8fAkTZZx+gF6+fScSf6n4e1jmxP7vdLmLv0L9rfmpz6ojnJCD6 Mm+WYXXQynfRHhixTPQ2mfBODyjl05Xf1LlnHGMPL9X7eiaXrCZInUXLGbHI61rCkP71WJrBMhvsx k7wEuvDWAdMpKuze0ju5ti0WEFAFFZkqMiQEw94DjA8YJHLjl6HDE/aE6nrxc1N2DK6+ReZOhR9R0 OKH0vQxzjJsEQ7BjpfR2CkR7qs0xEtKgyVjtUNvJAplriFlml3FWz2kS2PWo8t8wVfS6gWkkkifxG ssT0LnDZt6uJ2iysbMUN9Q==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1opuOz-0000Eq-9I; Tue, 01 Nov 2022 12:46:13 -0400 In-Reply-To: <87pmeev40u.fsf@posteo.net> (message from Philip Kaludercic on Wed, 26 Oct 2022 18:22:25 +0000) 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:298945 Archived-At: [[[ 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? 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. 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. 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. 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. 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? -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)