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

From: Philip Kaludercic <[email-masked]>
Date: Fri, 16 May 2025 15:36:44 +0000

Ship Mints <[email-masked]> writes:

> 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.

Can you please summarise the relevant parts of this discussion?  I see
that a patch is being mentioned above, should I review it?