On Wed, Mar 5, 2025 at 2:55 PM Ship Mints wrote: > On Wed, Mar 5, 2025 at 12:00 PM Ship Mints wrote: > >> On Mon, Mar 3, 2025 at 9:34 PM Stefan Kangas >> wrote: >> >>> Ship Mints writes: >>> >>> > As part of my production upgrade to 30.1, and before I wrote a program >>> to install my local >>> > ELPA tree from scratch, I tried to first curate my packages and change >>> from MELPA to >>> > generally equivalent GNU ELPA or non-GNU ELPA archives. The result >>> was that I had two of >>> > each package installed. >>> > >>> > I think there's a bug in 'package-install' which, when invoked from >>> > 'package-install-button-action', processes the new package spec, and >>> incorrectly checks to >>> > see if the package is already installed. Interactive invocation of >>> 'package-install' yields the >>> > package name from the prompt, not its archive description. >>> > >>> > If the below is correct, I can submit a patch to make >>> 'package-install' behave like >>> > 'package-reinstall' for the non-interactive case. >>> >>> Please submit a patch, but could we also have tests for this please? >>> >>> Thanks in advance. >>> >> >> Patch attached. It prevents the menu-driven case from erasing the >> already installed message. It could suggest to the user to remove and then >> install or we could offer to use package upgrade to the chosen >> package-desc. At the very least, the patch prevents duplicates. >> > > Thinking about it a bit more, this patch needs a little more work. The > menu-driven package "upgrade" in describe-package-1 workflow will be interrupted by > this patch. It does not differentiate install vs. upgrade and calls > package-install which will now complain the package already exists. This > should be changed to run package-upgrade. I'll take a look. > > Any feedback on the minimal patch is still welcome in the meantime. > This patch now accommodates both scenarios.