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 22:18:34 +0300 Message-ID: <83v8hye0hh.fsf@gnu.org> References: <87a5zj2vfo.fsf@gmail.com> <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> <87y1muefks.fsf@gmail.com> <835y9yfj68.fsf@gnu.org> <83zg7ae1ud.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="39405"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 62720@debbugs.gnu.org, rpluim@gmail.com, philipk@posteo.net, monnier@iro.umontreal.ca To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 14 21:19:29 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 1pnOxD-000A3j-OY for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Apr 2023 21:19:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pnOwp-0000UL-MS; Fri, 14 Apr 2023 15:19:03 -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 1pnOwo-0000Tn-I4 for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 15:19:02 -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 1pnOwo-0004Et-AS for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 15:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pnOwo-0007kj-5j for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 15:19: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 19:19: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.168149992629771 (code B ref 62720); Fri, 14 Apr 2023 19:19:02 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 14 Apr 2023 19:18:46 +0000 Original-Received: from localhost ([127.0.0.1]:47658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnOwY-0007k7-4b for submit@debbugs.gnu.org; Fri, 14 Apr 2023 15:18:46 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56504) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnOwW-0007jr-4b for 62720@debbugs.gnu.org; Fri, 14 Apr 2023 15:18:45 -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 1pnOwP-0004B8-KB; Fri, 14 Apr 2023 15:18:37 -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=6QWyZkiV+6SpygrtZVbYIqsr+Op9QT8XXeaJ3V9zzBM=; b=gZ1E4IkDfqSZI4jS+EGd mJQBLjr8P8s9hUxGa4u3cy6qmAUyJu5LG8e3sC44Gl40SKr8yH5crNW6eq+T99bLmOINHWT3Aw91F BTkx9mXfo3kSHRSxLLhOTKWh3D12j6AwTYvOtRt/OgKlBzDTT6bGFeB5452qmUKlFgGAiHhE36qjY 3N0mY15vuRGyUFMHHrUJDGUh6BWyAghxaNY5cu6zR47IsTE+U5c8HDm7QIckkk+LSEYDUe1E5zRO8 uLvfBFAQFOEtV4g4Xr4lg/P0tezce0SIZOIIZaxcEiFkXfiU+EeRZRYO3i5q5izAYDG9w5kBV9V4t brXR+9AUq+/cQA==; 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 1pnOwO-0004Bz-U3; Fri, 14 Apr 2023 15:18:37 -0400 In-Reply-To: (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Fri, 14 Apr 2023 20:03:31 +0100) 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:259965 Archived-At: > From: João Távora > Date: Fri, 14 Apr 2023 20:03:31 +0100 > Cc: monnier@iro.umontreal.ca, rpluim@gmail.com, 62720@debbugs.gnu.org, > larsi@gnus.org, philipk@posteo.net > > > > OK, but who does this and why, in your opinion? And who has > > > `(package-install seq)` in their config and why? And won't they get > > > the same updated 'seq' "accidentally" if they install anything else > > > that depends on newer seq, which is likely a lot of non-core > > > packages and likely to grow? > > > > I don't know. But we did have core packages that were also on ELPA > > before Emacs 29, and people did get along with that. So much so that > > I don't recall any complaints about this, definitely not complaints > > that claimed package.el is as badly broken as you seem to represent. > > I think it's simply and clearly because there weren't any non-core > packages that migrated to core before. Were there? Certainly > none with as fast a release cycle like Eglot's. You are missing the point. My point is that users of all those other core packages are used to the current situation, where package-install doesn't update the built-ins. They have workflows based on that. Those are the workflows that I don't want to risk breaking. Once the discussion with Philip runs to its completion, we _will_ have in Emacs 29.1 a way of upgrading built-ins, only not by default, but by an explicit user request. Maybe this is not ideal, but we don't have time to find out what is ideal for all those involved, and this partial solution allows to get the job done without risking to break anyone's workflow. So this is a good compromise, given the time and the constraints, at least from my POV. > > I said "in effect calling for breaking them". You need to realize > > this might be the outcome of what you are requesting, even if your > > intentions are benign. > > I _am_ realizing that, and even if I think the risks are minuscule, > I'm providing solutions that mitigate them. And -- responsibly, I > think -- pointing to the fact that the risk surface is much larger > than you may think it is. I respectfully disagree with your assessment of the risks. And eventually, it is my responsibility to do this job, so my assessment of that is what counts more. I've heard all of your arguments (and also those of others), and considered all of them, and I still don't think the risk is high enough to justify the potentially-breaking changes that you propose, not on the release branch, not this late into the release cycle. > > > I even proposed making a simple whitelist of packages that have > > > migrated from outside core to core. And I've proposed confirmation > > > prompts for the interactive calls. And others have proposed > > > blacklists. These things are trivial to implement in Elisp. > > > > They are not trivial enough to be considered for emacs-29. On master, > > sure, feel free to install such changes, if the others agree. > > Are you saying it's OK to propose this blacklist/whitelist idea? For the release branch? No. For master? Yes. > I will work and prepare that patch if you promise to at least > look at the code, follow the logic with me and consider the > patch for backporting if it's as safe as relying on a simple > `(if (memq package package-safely-upgradeable-builtins) ...)` Backporting can be considered for Emacs 29.2, not before that. Hopefully, by that time we will also have more data points regarding the various uses of this, in particular with Eglot, so that our decisions will be more informed.