bug#29586: Please revert change to package deletion

bug#29586: Please revert change to package deletion

[Adam Porter]

I'm disappointed to see the change made in response to the filing of
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14967> being released in
Emacs 26.

The preexisting behavior, to delete packages to the trash, was the safer
behavior.  In the event that an updated package caused a problem, a user
could restore the previous version from the trash.

Since ELPA/MELPA repositories only provide the latest version of a
package, the only other way to recover a previous version of a package
would be for a user to manually recover it from the package's version
control repo.  This is a laborious process, one which most users will
not even have the necessary knowledge to do; generally one would only
expect package developers to be able to do so in a reasonable amount of
time.  For other users, when their config becomes broken due to a new
package version, it's likely that they need to get some work done with
Emacs, and do not therefore have the time to debug such issues and
manually recover the previous version of a package.

This is not an everyday occurrence, but note that, given the relatively
haphazard way in which ELPA/MELPA (the latter, especially) packages are
released, this *does* happen, and inevitably it does so when one doesn't
have time to fix it.  Users who keep their ~/.emacs.d/{,elpa} under
version control have an easy fix for this, but in my estimation, having
been participating in such discussions and encouraging it, this remains
a small minority of users.  Therefore, having old package versions in
the trash is a desirable behavior, in the general best-interests of
users.

The original bug report complained of, "cluttering the user's trash
can."  This is a very poor justification for the change that was made,
to claim that the *trash can* is being cluttered.  The trash can is the
designated receptacle for such clutter, and is designed to be emptied
with a single action.  I cannot fathom real users lamenting that their
*trash can* is cluttered with *trash*.

As well, please note that the original complainant, despite having
significantly contributed to the Emacs community in several ways, has
since aggressively removed himself from the community in general
protest, and is no longer even an Emacs user.

It's especially disappointing, given that a patch
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14967#36> was posted to
make the behavior configurable, but instead the new, less-safe behavior
was hard-coded.

Finally, the original bug report languished for 3 years without any
other users requesting that the behavior be changed, and then another
year passed before the change was actually made.  Given this, it seems
like this change was essentially made to satisfy the whim of a single
user, who now, very publicly, no longer uses Emacs.

Therefore, please consider reverting this change before Emacs 26 is
released, to avoid this user-unfriendly change being officially released
into the wild.

Thanks for your work on Emacs.

bug#29586: Please revert change to package deletion

[John Wiegley]

>>>>> "AP" == Adam Porter <adam@alphapapa.net> writes:

AP> The original bug report complained of, "cluttering the user's trash can."
AP> This is a very poor justification for the change that was made, to claim
AP> that the *trash can* is being cluttered. The trash can is the designated
AP> receptacle for such clutter, and is designed to be emptied with a single
AP> action. I cannot fathom real users lamenting that their *trash can* is
AP> cluttered with *trash*.

I tend to agree with Adam on this point. As a user, I'd prefer such things to
accumulate in my trash so that I could undo them; I really don't care what's
in the trash, just that's useful for undeleting things. Most operating systems
provide ways to periodically tidy up the trash, so I'm somewhat surprised that
a bug was issued to this fact.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#29586: Please revert change to package deletion

[Eli Zaretskii]

> From: "John Wiegley" <johnw@gnu.org>
> Date: Tue, 05 Dec 2017 16:46:13 -0800
> Cc: 29586@debbugs.gnu.org
> 
> >>>>> "AP" == Adam Porter <adam@alphapapa.net> writes:
> 
> AP> The original bug report complained of, "cluttering the user's trash can."
> AP> This is a very poor justification for the change that was made, to claim
> AP> that the *trash can* is being cluttered. The trash can is the designated
> AP> receptacle for such clutter, and is designed to be emptied with a single
> AP> action. I cannot fathom real users lamenting that their *trash can* is
> AP> cluttered with *trash*.
> 
> I tend to agree with Adam on this point. As a user, I'd prefer such things to
> accumulate in my trash so that I could undo them; I really don't care what's
> in the trash, just that's useful for undeleting things. Most operating systems
> provide ways to periodically tidy up the trash, so I'm somewhat surprised that
> a bug was issued to this fact.

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

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"?

bug#29586: Please revert change to package deletion

[Glenn Morris]

I don't have a strong opinion, but:

I don't know of any package management system that when uninstalling a
binary package moves all the files to a trash directory. It seems to me
this is being used in lieu of some features other package systems do
implement, and that package.el could benefit from:

a transaction history
a downgrade command
a rollback command
caching of the _source_ when installing a package
package archives that provide convenient access to old versions
 (maybe this exists for elpas, I don't know)

bug#29586: Please revert change to package deletion

[Adam Porter]

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.

bug#29586: Please revert change to package deletion

[John Wiegley]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

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

Not to be contentious, but how much of an impact could that really have for
Emacs packages? I use >350 packages, and my site-lisp is 400M. Even if I
auto-updated everything, every day, that's *still* ~1% of my disk, which is
what I usually allocate for trash accumulation.

Your argument that no other package system replaces packages by moving them to
the trash is valid, though; I don't know of any that do that. Thus, I can't
argue that it's the right thing to do here.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#29586: Please revert change to package deletion

[Eli Zaretskii]

> From: John Wiegley <johnw@gnu.org>
> Cc: adam@alphapapa.net,  29586@debbugs.gnu.org
> Date: Fri, 08 Dec 2017 21:50:31 -0800
> 
> >>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> EZ> The problem is that many users have their packages auto-updated, so the
> EZ> trash piles up quite quickly.
> 
> Not to be contentious, but how much of an impact could that really have for
> Emacs packages? I use >350 packages, and my site-lisp is 400M. Even if I
> auto-updated everything, every day, that's *still* ~1% of my disk, which is
> what I usually allocate for trash accumulation.

The disk space is not the issue, I think, not nowadays.  I believe the
issue is the _number_ of files in the trash: if there are an awful lot
of them, they make looking for those "precious" mistakenly deleted
files harder.  Or at least this is my understanding; I don't use
trash, so have no experience of my own to share.

bug#29586: Please revert change to package deletion

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> The disk space is not the issue, I think, not nowadays. I believe the issue
> is the _number_ of files in the trash: if there are an awful lot of them,
> they make looking for those "precious" mistakenly deleted files harder. Or
> at least this is my understanding; I don't use trash, so have no experience
> of my own to share.

That I can buy. A daily update in my case would result in half a million files
over the course of a month.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#29586: Please revert change to package deletion

[Adam Porter]

On Sat, Dec 9, 2017 at 3:08 AM, John Wiegley <johnw@gnu.org> wrote:
>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
>> The disk space is not the issue, I think, not nowadays. I believe the issue
>> is the _number_ of files in the trash: if there are an awful lot of them,
>> they make looking for those "precious" mistakenly deleted files harder. Or
>> at least this is my understanding; I don't use trash, so have no experience
>> of my own to share.
>
> That I can buy. A daily update in my case would result in half a million files
> over the course of a month.

That's not an unreasonable concern, however there are (or ought to be)
some mitigating factors:

1.  Emacs should move the package directory to the trash, not the
individual files within it.  This will appear as a single directory in
the trash.
2.  Trash bin UI should provide filtering and sorting to easily narrow
down what's in it.  For example, using Dolphin in KDE, there is
extensive sorting, by deletion date, original path, filename, size,
etc.  And there's a filter-as-you-type bar to narrow results quickly.

Of course I have no objection to Emacs users who don't want this
behavior.  If the patch I mentioned were merged, everyone could have
the behavior they want instead of it being hard-coded one way or the
other.

bug#29586: Please revert change to package deletion

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The disk space is not the issue, I think, not nowadays.  I believe the
> issue is the _number_ of files in the trash: if there are an awful lot
> of them, they make looking for those "precious" mistakenly deleted
> files harder.  Or at least this is my understanding; I don't use
> trash, so have no experience of my own to share.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

As far as I can tell, package.el package-delete still deletes (and
doesn't trash) the files, and I can't recall seeing any requests to
change this (outside this bug report), so there doesn't seem to be any
great demand for that, and I'm therefore closing this bug report.

(People that want this can now advise `package--delete-directory', so
it's easier to change the behaviour in Emacs 28 than it was in previous
versions.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no