GNU bug report logs -
#76568
'package-install' should not install duplicate packages
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]
This bug report was last modified 56 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.