Ship Mints <shipmints@gmail.com> 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.