Re: Changes to `make-obsolete` and similar functions make upgrades nearly impossible.

[Platon Pronko <platon7pronko@gmail.com>]

On 2023-04-23 21:56, Lloyd Zusman wrote:
> I'm a very long-term GNU emacs user: since the 1980's.
> 
> I have been using numerous elisp packages, lots of which date
> back many years, and a few of my own elisp modules go all the
> way back to the 1980's.
> 
> I have been using emacs-27.2 for a few years, and now I decided
> to upgrade again. However, when going to emacs-28.2, I hit an
> issue with the following emacs enhancement (this comes from the
> emacs change log):
> 
>> 2021-01-03  Stefan Monnier  <monnier@iro.umontreal.ca>
>>
>>        * lisp/emacs-lisp/byte-run.el (make-obsolete): Make `when` mandatory
>>
>>        (define-obsolete-function-alias, make-obsolete-variable)
>>        (define-obsolete-variable-alias): Adjust similarly.
> 
> Because of `when` becoming mandatory, I now get literally hundreds
> of messages which look like this when starting up emacs-28.2 ...
> 
>> Warning (comp): /path/to/some-elisp-module.el: Error: Wrong number of arguments make-obsolete-variable
> 
> I know that I can get rid of these messages by upgrading each and
> every one of my installed emacs packages. However, I have several
> dozens of these packages, and some are old, no-longer-maintained
> modules. It would take me a huge amount of time to replace the
> packages that are upgradable and to manually go into all of the
> no-longer-maintained packages and change the calling sequence of
> `make-obsolete` and the others.
> 
> If the `when` parameter was not made mandatory in `make-obsolete`
> and its cousins, I would not have to do this huge amount of work
> to upgrade emacs.

The commit message for the change states that usages without `when` were marked obsolete
in version 23.1, which was released in 2009 (14 years ago).

It seems you have dozens of packages that haven't been updated for 14+ years.

While some may argue the "security" aspect, I won't,
because I don't fully agree that everyone needs
  to sacrifice everything for imaginary "security."
Old, tried, and tested software can be great.

However, I question the wisdom of upgrading one part of the system
without upgrading everything else. If you're okay with running such ancient packages,
maybe you don't need to upgrade Emacs?
Even the 23.1 release should compile and run fine today.


In general, there are two approaches to upgrades:

1. Gradually and in sync update everything (e.g., rolling releases like Arch Linux are a great example).
    This approach spreads the pain of breakage evenly over time, and you get to enjoy the benefits of fresh software.

2. Fix everything at a single point in time, and keep it that way for a long time.
    This brings the benefit of stability and everything working exactly the same at all times.
    However, at some point, you might need to upgrade, and then you'll have to endure the pain
    of upgrading everything at once, with many things breaking down and needing a complete overhaul.

I don't think that anything in between these approaches really works –
you'll get downsides of both approaches without much benefit.


> The `make-obsolete` family of functions are meant to help during
> upgrading. However, changing the mandatory/non-mandatory parameter
> semantics of those functions is actually an *impediment* to
> upgrading.
> 
> Is there any existing fix for this problem short of the massive
> amount of work needed for me to upgrade and fix all my existing
> emacs packages?

Perhaps contributing back to the community by fixing the packages might be the best way forward?
This task involves relatively straightforward and easy changes, something that can be done in several hours at most.

> I'm thinking of doing something like the following. Put code like
> this at the top of my $HOME/.emacs file:
> 
>> (if (not (fboundp 'orig-make-obsolete))
>>     (fset 'orig-make-obsolete
>>           (symbol-function 'make-obsolete)))
>> (fmakunbound 'make-obsolete)
>> (unintern 'make-obsolete)
>> (defun make-obsolete (obsolete-name current-name &optional when-var)
>>   (when when-var
>>       (orig-make-obsolete obsolete-name current-name when-var)))
> 
> ... or something like that.
> 
> Is this kind of workaround my only hope for avoiding the huge amount
> of work necessary to upgrade and fix the code in all of my existing
> emacs packages?

This workaround (or something similar) should work. However, consider other deprecations,
obsoletions, and breakages that have accumulated over the years.
At some point, you'll still need to bite the bullet and upgrade.

-- 
Best regards,
Platon Pronko
PGP 2A62D77A7A2CB94E