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

From: Ship Mints <[email-masked]>
Date: Fri, 16 May 2025 11:42:26 -0400

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