Subject: bug#76568: 'package-install' should not install duplicate packages

From: Ship Mints <[email-masked]>
Date: Sat, 10 May 2025 07:35:27 -0400

On Thu, Mar 20, 2025 at 10:41 AM Ship Mints <[email-masked]> wrote:

> On Fri, Mar 7, 2025 at 6:33 AM Ship Mints <[email-masked]> wrote:
>
>> On Wed, Mar 5, 2025 at 4:05 PM Ship Mints <[email-masked]> wrote:
>>
>>> On Wed, Mar 5, 2025 at 4:02 PM Ship Mints <[email-masked]> wrote:
>>>
>>>> On Wed, Mar 5, 2025 at 2:55 PM Ship Mints <[email-masked]> wrote:
>>>>
>>>>> On Wed, Mar 5, 2025 at 12:00 PM Ship Mints <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> On Mon, Mar 3, 2025 at 9:34 PM Stefan Kangas <[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>>> Ship Mints <[email-masked]> 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.