Package: emacs;
Reported by: Ship Mints <shipmints <at> gmail.com>
Date: Tue, 25 Feb 2025 20:53:01 UTC
Severity: normal
Tags: patch
Message #46 received at 76568 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: philipk <at> posteo.net, Ship Mints <shipmints <at> gmail.com> Cc: 76568 <at> debbugs.gnu.org, stefankangas <at> gmail.com Subject: Re: bug#76568: 'package-install' should not install duplicate packages Date: Sat, 24 May 2025 12:13:19 +0300
Ping! Can we make some further progress in this matter? > From: Ship Mints <shipmints <at> gmail.com> > Date: Fri, 16 May 2025 11:42:26 -0400 > Cc: Stefan Kangas <stefankangas <at> gmail.com>, 76568 <at> debbugs.gnu.org, > Eli Zaretskii <eliz <at> gnu.org> > > On Fri, May 16, 2025 at 11:36 AM Philip Kaludercic <philipk <at> posteo.net> wrote: > > Ship Mints <shipmints <at> gmail.com> writes: > > > On Thu, Mar 20, 2025 at 10:41 AM Ship Mints <shipmints <at> gmail.com> wrote: > > > >> On Fri, Mar 7, 2025 at 6:33 AM Ship Mints <shipmints <at> gmail.com> wrote: > >> > >>> On Wed, Mar 5, 2025 at 4:05 PM Ship Mints <shipmints <at> gmail.com> wrote: > >>> > >>>> On Wed, Mar 5, 2025 at 4:02 PM Ship Mints <shipmints <at> gmail.com> wrote: > >>>> > >>>>> On Wed, Mar 5, 2025 at 2:55 PM Ship Mints <shipmints <at> gmail.com> wrote: > >>>>> > >>>>>> On Wed, Mar 5, 2025 at 12:00 PM Ship Mints <shipmints <at> gmail.com> > >>>>>> wrote: > >>>>>> > >>>>>>> On Mon, Mar 3, 2025 at 9:34 PM Stefan Kangas <stefankangas <at> gmail.com> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Ship Mints <shipmints <at> 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. > >> > > > > 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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.