On Wed, Mar 5, 2025 at 4:02 PM Ship Mints wrote: > 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. > Now with an amended commit log.