From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= 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:31:34 +0100 Message-ID: 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> <83v8hye0hh.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23205"; 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: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 14 21:30:20 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 1pnP7k-0005rj-GR for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Apr 2023 21:30:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pnP7Z-0003gZ-8z; Fri, 14 Apr 2023 15:30:09 -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 1pnP7V-0003c1-EN for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 15:30:05 -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 1pnP7S-000279-M4 for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 15:30:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pnP7S-00086X-Ht for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 15:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 19:30: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.168150058631107 (code B ref 62720); Fri, 14 Apr 2023 19:30:02 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 14 Apr 2023 19:29:46 +0000 Original-Received: from localhost ([127.0.0.1]:47740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnP7C-00085e-49 for submit@debbugs.gnu.org; Fri, 14 Apr 2023 15:29:46 -0400 Original-Received: from mail-oo1-f52.google.com ([209.85.161.52]:46916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnP7A-00085S-EI for 62720@debbugs.gnu.org; Fri, 14 Apr 2023 15:29:45 -0400 Original-Received: by mail-oo1-f52.google.com with SMTP id f7-20020a4ab647000000b0054101f316c7so6219315ooo.13 for <62720@debbugs.gnu.org>; Fri, 14 Apr 2023 12:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681500578; x=1684092578; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OhM1RkG5pIIFk77a1NP6WM2TCdPjVW1PPNP11/Grxck=; b=CzlWVZcnYkbCBo6NfO3i/9z/L857HTQDXSzO/i3sh0TMOClIDXWJuK+cIAWpzZZg2n DB6T7vE8co/uOA21R6QETcNm+Ss72O9Tt7zr5+aMSvyUT89eP+uOE87FISCoeYFdAGyy 9/Gu3JjaJwSl5/X4YHacYlugYAsY+/8eATrUt1J4l2wwG+7pa8PUxuYG8kXgG/+OzfFC /rW3dNhpmgv/+RHYszHBFgTCb51Nl5gNRXilzgb4Qj8TFFQAU2pR1itkTP/w9Cb1viQr e5Q/KHwUf33DNa1XYNu4vf/cbXCnkY1kK1ixzGSaneIh0xE7XB44haihIT/jYtNHlMT7 LWXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681500578; x=1684092578; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OhM1RkG5pIIFk77a1NP6WM2TCdPjVW1PPNP11/Grxck=; b=MkO704nZVP3QMKmHWYyMIHEaYbTAfG9qxclNeAsonsPoNzHJRpk03sd1rPGducnv42 Cqf4yjdfVfLLKCsjQJYgpA9MFRB8Df+OscFEkB5f4ePZ3Xi8MVNgO7upEF7t/fEDNQR9 Gskx68esRWCUHMLCMsxHZnMci7GFZ8GVqdD60JvcyqxkYnNhDqsfQ+Jc1TO6GXUXuuwg AwrSl794Y607Q2Ee6IxwCUtnKEx2xYLx8gNN81xU5eDEcjJHCqWHVE9qlsQkeKqC/Efl i57WqBL9ga4/Kl33kxwAzBreTXZhA9ijwbBDR1DlfIEiwpvzV5Re+Tqsb2DR3z5D93dZ EzmQ== X-Gm-Message-State: AAQBX9cH9/Jd4g+Yw+vZ79p6856sICZXulHR5M7btXWhX59J6xAgTten o3b8hooA5gqMX5377bhOx3rtZn6VJIDC+w8ZBWs= X-Google-Smtp-Source: AKy350ZZsbQDG7G1EwrG3irCtqTt8JnQAUflSVJBCSFhuV5xFlUE8z/NJqpBxcFz4rWJfQmDtXcjkJcqNSxFHoePQcw= X-Received: by 2002:a05:6820:8c2:b0:538:d154:cbc2 with SMTP id bi2-20020a05682008c200b00538d154cbc2mr2283842oob.1.1681500578706; Fri, 14 Apr 2023 12:29:38 -0700 (PDT) In-Reply-To: <83v8hye0hh.fsf@gnu.org> 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:259969 Archived-At: On Fri, Apr 14, 2023 at 8:18=E2=80=AFPM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > 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 ge= t > > > > 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. The only workflows that traverse this use case I can think of: 1. they routinely invoke a useless M-x package-install RET seq RET , it prints "already installed" and they breathe a daily sigh of relief. 2. they have `(package-install 'seq)` somewhere in their init file which runs daily and does nothing. > 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. There is already this way, that was never in question. Package menu, M-: or anything else, it's not _that_ hard. But it's a shame that the canonical use-package recipe for Eglot (or for use-package itself) it will break. Looking at the patches, it seems, from my POV, that using a prefix argument and an extra customization option is much, much more complicated than a simple whitelist or blacklist that the user needn't ever see. > > 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. And even though I also disagree, equally respectfully, with your assessment of the risks, and still I'm providing a solution that eliminates them totally. > > 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. OK. Fair enough. If there's half a chance for 29.2 I guess I can work on it. Not today though. Jo=C3=A3o