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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 24 May 2025 12:13:19 +0300

Ping!  Can we make some further progress in this matter?

> From: Ship Mints <[email-masked]>
> Date: Fri, 16 May 2025 11:42:26 -0400
> Cc: Stefan Kangas <[email-masked]>, [email-masked], 
> 	Eli Zaretskii <[email-masked]>
> 
> On Fri, May 16, 2025 at 11:36 AM Philip Kaludercic <[email-masked]> wrote:
> 
>  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?
> 
> The latest version of this patch from this discussion is attached.  It amends both the menu-driven package
> upgrade and the package-upgrade command to assist the user with avoiding (or permitting) installing a
> package more than once.
> 
> I introduced "tangents" in the discussion along the way as I learned more about the package infrastructure:
> 
> "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?"
> 
> -Stephane