bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot

["João Távora" <joaotavora@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]

On Wed, Apr 12, 2023, 17:52 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: João Távora <joaotavora@gmail.com>
> > Date: Wed, 12 Apr 2023 17:13:27 +0100
> > Cc: Philip Kaludercic <philipk@posteo.net>, monnier@iro.umontreal.ca,
> 62720@debbugs.gnu.org,
> >       larsi@gnus.org
> >
> > On Wed, Apr 12, 2023 at 4:17 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > The above questions and undocumented subtleties is what scares me in
> > > installing such changes at this late stage.  I'm not sure everyone
> > > involved, yourself included, have a clear understanding of what the
> > > modified code will do in each possible use case.  That is why I very
> > > much prefer separate code, which will then free us from the need of
> > > considering all these subtleties, as the last year of user's
> > > experience with this code can vouch that it does its job correctly, by
> > > and large.
> >
> > Alright, I've tried my hand at making this clean separation, so that
> > no logic of transaction or existing predicates is touched.  I tried to
> > make it as intelligible as possible perhaps overdoing the commentary
> > and the naming, but we can always trim it.
>
> Thanks, but this is not separate code.  It adds 21 built-in packages
> to the list of completion candidates that the user can choose in
> package-install, and who knows what kind of confusion this could cause
> when users see packages like Xref and Package and Tramp and seq and
> Python and Org in that list, and what accidents that could cause if
> users select one of those by mistake, because they never saw them
> there before?
>

The intended behavior, of course. To install a newer version of the
package, of course. This is also what Philip's patch did, only with
different code.

PLEASE show me a completely separate code or a separate command, then
> I will agree to this last-minute addition.
>

The point is to change the broken behavior of the existing command,
package-install. Anything else is a waste of time, and noone except you has
demonstrated support for this separate command idea. Please, in normal
non-shouting case, explain to me how you think that the behavior of an
existing command can be changed with "completely separate code".

João

>

[-- Attachment #2: Type: text/html, Size: 3663 bytes --]