From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot Date: Fri, 14 Apr 2023 20:43:16 +0300 Message-ID: <837cuefjgr.fsf@gnu.org> References: <87a5zj2vfo.fsf@gmail.com> <87r0sptinq.fsf@posteo.net> <83jzyh706c.fsf@gnu.org> <875ya1tdwf.fsf@posteo.net> <83edop6sdy.fsf@gnu.org> <831qkp6o0i.fsf@gnu.org> <83wn2h5825.fsf@gnu.org> <87wn2gkhzr.fsf@posteo.net> <83cz485oxi.fsf@gnu.org> <87leiwdyff.fsf@posteo.net> <834jpk5hih.fsf@gnu.org> <871qkom3fj.fsf@posteo.net> <83mt3b4yfc.fsf@gnu.org> <87edonlsxi.fsf@posteo.net> <83jzyf4vzb.fsf@gnu.org> <871qknllkj.fsf@posteo.net> <83fs934pjf.fsf@gnu.org> <87wn2fk47y.fsf@posteo.net> <83sfd2g2ek.fsf@gnu.org> <875y9yfxrr.fsf@gmail.com> <83jzyefuq1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7775"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, rpluim@gmail.com, 62720@debbugs.gnu.org, joaotavora@gmail.com, larsi@gnus.org, monnier@iro.umontreal.ca To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 14 19:44:16 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pnNT5-0001nd-VM for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Apr 2023 19:44:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pnNSv-0001Z5-NU; Fri, 14 Apr 2023 13:44:05 -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 1pnNSt-0001X4-VM for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 13:44:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pnNSs-000681-Cp for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 13:44:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pnNSs-0004xY-8a for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 13:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 17:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62720 X-GNU-PR-Package: emacs Original-Received: via spool by 62720-submit@debbugs.gnu.org id=B62720.168149421319019 (code B ref 62720); Fri, 14 Apr 2023 17:44:02 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 14 Apr 2023 17:43:33 +0000 Original-Received: from localhost ([127.0.0.1]:47519 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnNSO-0004wf-PM for submit@debbugs.gnu.org; Fri, 14 Apr 2023 13:43:33 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnNSM-0004wQ-4w for 62720@debbugs.gnu.org; Fri, 14 Apr 2023 13:43:31 -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 1pnNSG-0005xh-6k; Fri, 14 Apr 2023 13:43:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=BmBAnX30v4cI9DkZxrjw2yH38Le86xUze3jaPQ+dPB0=; b=Ms1hQpQO7+cXkaMLmWU1 RKgsW8+Fky4GBEpDuN0kcVe/XSVbj0Y2jctTG/rlQM1J5Iw+DCVD0v4VHotoaIL45+Hd2KHkLjiT8 It0i05l/t2jLIqyOgkYKzBpBjWEpIf3CymVJEJJ59nPhAj9u+VqRl57EFj8hEF37mirSdotsBVm2j 0gfYeSh43iHCcJvcHjikVvCQgAlAWAMGgTfraWOWSOMhcNO0rCgLdCc0S4mE1COYpRIC641CWS/WG VoTLJSATmN3TII5ONsHbOsYLeea1Uoo22ZbqzQY2NU8LGEaePW5+6ucS7PM+EvyUXtClk1kuVQi0b pLo5ni4oAiFbAw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pnNSB-0005e8-So; Fri, 14 Apr 2023 13:43:23 -0400 In-Reply-To: (message from Dmitry Gutov on Fri, 14 Apr 2023 19:04:20 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:259946 Archived-At: > Date: Fri, 14 Apr 2023 19:04:20 +0300 > Cc: 62720@debbugs.gnu.org, philipk@posteo.net, larsi@gnus.org, > monnier@iro.umontreal.ca, joaotavora@gmail.com > From: Dmitry Gutov > > On 14/04/2023 16:40, Eli Zaretskii wrote: > >> So on master if I upgrade all packages, ':core' packages would be > >> automatically upgraded as well? > > is that what the default of that option means? > > > >> I strongly object to that as a default; just because thereʼs a newer > >> version on elpa of a :core package doesnʼt mean emacs should upgrade > >> to it unless*explicitly* told to do so. > > I said we_can_ change the default; I didn't say we_must_. If enough > > people object to making that the default, it won't be changed. > > We need to have a change in behavior that allows 'M-x package-install' > to upgrade built-in packages. But that shouldn't automatically mean that > package-menu-mark-upgrades marks all built-in packages for upgrade, or > package-upgrade-all (nee package-update-all) does that either. > > We could have another option that enables the latter to upgrade all > built-ins too, of course. > > Regarding the currently proposed user option, does it make sense to you > to have such option that decides whether package-install upgrades > built-ins? Whereas one can always upgrade a built-in package using 'i' > (package-menu-mark-install) in the list-packages menu, no matter the > value of that option. I get the backward-compatibility intent, but user > options should also do something logical from a user's point of view. All these questions should have been raised and discussed months ago. Then we could have done the best for the users (what that is, is still unclear even at this point). Now it's too late, and the main factor that will decide how Emacs 29.1 will behave in that regard is whether the changes to implement that are safe enough to go into Emacs 29.1. To answer your question more specifically: yes, it does make sense to me. The logic, so it seems, is in the eyes of the beholder, and my eyes do see a certain logic there.