bug#29586: Please revert change to package deletion

[Adam Porter <adam@alphapapa.net>]

On Fri, Dec 8, 2017 at 4:47 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> The problem is that many users have their packages auto-updated, so
> the trash piles up quite quickly.

Is that a problem, though?  It's not for me.  I have plenty of disk
space, and I don't even look at the trash for weeks or months at a
time.  Then I can empty it with a single command, or I have a Python
script that works with XDG trash bins that can delete all trashed
items older than a certain time.  There are also desktop environments
that can delete trash automatically (e.g. KDE).

> The usual justification for trash is that you may be inadvertently
> deleting something precious.  Here we are talking about downgrading to
> a previous version of a package, which, while perhaps somewhat
> inconvenient, is not impossible.  So why fill up the user's trash with
> stuff that can be recovered "by other means"?

As best I can tell, the typical process to recover old package
versions by other means would look like this:

1.  Already know how to use git or whatever VC the package author uses.
2.  Find package's web site or VC repo, either through
describe-package or looking at the source file.
3.  Clone the repo locally.
4.  Figure out which previous commit corresponds to the version which
was previously installed.  (This is a non-trivial step: without having
the previous version's files available, the user may be left to simply
guess what the old version string was.  If he can determine that, he
can guess which commit corresponds to it by date.  If he can't
determine the old version string, he essentially has to look at the
commit log and figure out, from the contents of each commit, which one
is most likely to still work on his config.)
5.  Check-out that commit.
6.  Actually use that commit in his Emacs config.  (If it's a
single-file package, he might simply load the file, or open it and
eval the buffer.  If it's a multi-file package, this process is
laborious and error-prone, as the files must be loaded in the correct
order.  Alternatively, he could add the directory to his load-path,
delete the broken, installed version of the package, and restart
Emacs.  None of these steps are likely to be feasible for users who
are not also package developers.)

In contrast, if he could restore the old version from the trash, the
process would look something like:

1.  Uninstall current version of the package.
2.  Restore old version's directory from the trash.
3.  Restart Emacs.

Most Emacs users could do this much more easily.  They might not know
that the old version is in the trash, but someone on e.g. /r/emacs or
IRC could easily describe that process to them.  But describing the
other process to someone who doesn't already know how to do those
things is not a promising scenario, especially in the case that the
user needs to get something done quickly and needs his config to just
work like it used to.

Glenn makes a good point, and it would be great if package.el could do
those things someday.  But if that ever happens, it's a long way off,
and being able to restore old versions from the trash is a simple,
cheap way to safeguard against such common breakage (as an example,
not to criticize John, but even use-package had changes in the past
few days which caused some breakage in users' configs, and it would
have been simple for them to simply restore the old version until a
fix was published).  It's also the way it's worked for many years now.