On Thu, Mar 20, 2025 at 10:41 AM Ship Mints wrote: > On Fri, Mar 7, 2025 at 6:33 AM Ship Mints wrote: > >> On Wed, Mar 5, 2025 at 4:05 PM Ship Mints wrote: >> >>> 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. >>> >> >> Attached patch with improved package replacement prompt. >> > > Here's a refined version of the patch which allows users to optionally > replace already-installed packages, or install/keep both. > > Testing this revealed some interesting other issues which may already be > known. I'll see if I can find bug reports and if not I'll submit new > ones. One example is that packages from different archives have > incompatible version numbering schemes which causes false positives with > the obsolete package detection mechanism. Another is that > package-reinstall does not respect the originating archive, instead > preferring package-archive-priorities which may install a different version > than is expected by a user. Now might be a good time to consider that > packages should be installed in archive-specific subdirectories rather than > commingling them? > > I'd appreciate it if some others would look at this and test it. It might > be adequate as a stop-gap for its intended purpose to avoid casual > duplicate installs and some feedback would help. > This bug/patch seems to have languished. It would be good to get it done. Duplicate installed packages are annoying to say the least.