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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 19 Apr 2023 19:27:11 +0100
> Cc: dmitry@gutov.dev, rpluim@gmail.com, philipk@posteo.net, 
>       62720@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca
> 
> On Wed, Apr 19, 2023 at 6:59 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > No, I suggest that you make changes on master so that these problems
> > are avoided in the first place.  Changes in a core package on the
> > Emacs master branch should be done while keeping in mind that this
> > same version of a package will be on ELPA and users of older Emacsen
> > will install that newer version.  So the newer version on master
> > should avoid making changes which would mandate newer versions of
> > other packages, by providing the necessary compatibility fallbacks.
> 
> So, if I want to do a feature on master that depends on some
> new infrastructure on package X that appeared on master (say Xref's
> upcoming support for "find any type of thing declaration/macro/etc"),
> I have to do no less than duplicate that new infrastructure in Eglot.el
> and do a runtime check.

Not necessarily duplicate.  That is only one alternative, and not the
best one, IMO.  Other alternatives could be:

  . decide that users who use this new version of Eglot without that
    new version of Xref will not have this new Eglot feature
  . provide a less functional and simpler replacement for that Xref
    feature
  . find a way of providing the new Eglot feature without relying on
    Xref, but via some alternative solution

Whether each one of the above could be relevant and reasonable depends
on what exactly are those Eglot and Xref features.

I'm sure you don't need the above, you know that better than I do.
It's stuff we do in Emacs every day, and core packages consider these
factors since we began having core packages.  The question is just how
far to go in that direction.  I'm trying to make a point that going as
far as is practical will allow us to bundle at least some packages in
newer versions, which in the end will benefit users.

> AFAICT basically suggesting all Package-Requires are eliminated,
> to get rid of package.el dependency system.

No!  Not "all dependencies eliminated", that's impractical.  I'm
talking only about dependencies on core packages, and I'm asking to
avoid mandatory updates to newer versions.  The dependencies should
still exist, but the minimum supported version of each dependency
should ideally barely change, or at least change as infrequently as
possible.

> You should argue for that in emacs-devel explicitly so

That's what I did.  I'm not to bl;ame that you keep responding here
when I asked a day ago to respond to the discussion I started on
emacs-devel.