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

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 62720 <at> debbugs.gnu.org, "Philip K." <philipk <at> posteo.net>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Wed, 12 Apr 2023 18:14:28 +0100

[Message part 1 (text/plain, inline)]

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

> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Wed, 12 Apr 2023 17:13:27 +0100
> > Cc: Philip Kaludercic <philipk <at> posteo.net>, monnier <at> iro.umontreal.ca,
> 62720 <at> debbugs.gnu.org,
> >       larsi <at> gnus.org
> >
> > On Wed, Apr 12, 2023 at 4:17 PM Eli Zaretskii <eliz <at> 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

>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.