Better handling for duplicate packages - a "do-over" feature

[Kevin-Prichard]

Pre-submit checks

• I checked for similar issues beforehand, but could not find any. I could not add my proposal to any existing issue.
• I am going to take the time to to fill in all the required details. I know that the bug report will be dismissed otherwise.

Feature description

This is a general problem, and I'm presenting a specific example. This (likely) is not a FreeCAD problem, but not 100% certain.

1. I had an existing AppImage, FreeCAD 0.21.1, which I would run from the commandline:

• /opt/FreeCAD/FreeCAD_0.21.1-Linux-x86_64.AppImage

2. But I also had a prior version of FreeCAD, 0.19, installed via Debian's apt, which lives in /usr/bin and has an icon on the sidebar menu via a .local desktop file it installed (this seems to contribute to the problem you're about to read)

3. One day I decided that me launching AppImages from bash was an inconvenience, looked around for some automation, then found and installed appImageLauncher. I configured it to store appimages under /opt/Applications, and monitor ~/Downloads.

I then manually launched the FreeCAD 0.21 appimage one more time, which appImageLauncher correctly intercepted, and prompted me to do its thing, to which I agreed, and the FreeCAD 0.21 appimage was moved under /opt/Applications.

4. But when the FreeCAD 0.21.1 appimage ran, it temporarily "took over" the FreeCAD 0.19 menu icon (I later deduced), showing the little red dot indicating the app was currently running.

5. Then I quit the running FreeCAD 0.21.1 instance.

6. I clicked on the sidebar menu's FreeCAD icon, and FreeCAD 0.19 was executed. Huh?

7. I quit FreeCAD 0.19 and then ran sudo apt remove freecad which upon running apt list --installed | grep -i freecad appeared to have worked. A which freecad indicated there was no other version of FreeCAD available.

8. But now the sidebar menu icon for FreeCAD 0.19 was gone, and no icon for 0.21 appeared in its place. So, in the hopes its icon would be added to the menu by appImageLauncher, I ran FreeCAD 0.21 from shell again. It ran, and presented its icon on the sidebar menu below the bar separating Favorites from running apps that aren't favorites. But that icon is temporary, appears for the duration of the program's execution.

What I expected was for appImageLauncher to install an icon for the FreeCAD 0.21.1 appimage onto the sidebar menu. It did not.

My hypothesis is- while appImageLauncher "installed" FreeCAD 0.21 under /opt/Applications, it checked the sidebar for a "FreeCAD" entry, saw one already existed, and skipped adding the icon & corresponding .desktop file.

9. Finally, I hit the superkey to get Gnome's system-wide file search bar, typed in FreeCAD, and found a FreeCAD app (the appimage now being handled by appImageLauncher). I right-clicked and hit 'Add to Favorites'.

Now there is a FreeCAD icon on the sidebar menu. When I click it the FreeCAD 0.21 appimage executes, BUT a second FreeCAD icon appears on the sidebar menu, beneath the Favorites.

At least I have a clickable icon, now. But the multiple icons is an oddity. I guess this is a second problem in addition to the first.

Proposed solution

When checking whether a .desktop entry exists for an app being "installed" by appImageLauncher, present a dialog informing them of this, and offering the option of ignoring the existing one and installing a new one side by side. Multiple versions from multiple packaging systems is a thing nowadays (apt/dpkg, flatpak, snap, AppImage to name a few).

Alternative solutions you considered

I covered this under 'Feature description', but to synopsize-

1. When "installing" an appimage, check whether an existing .desktop (or equivalent) launcher file exists that conflicts with the new one coming in. If that happens, present a dialog informing the user, and offering to either a) overwrite the existing .desktop, or b) create the new .desktop with a unique, incrementally named version of the existing: [Desktop Entry].Name="FreeCAD" => "FreeCAD (1)" or n+1 if an existing "<app_name> \((\d+)\)" name exists

2. When launching an app, ensure that the running app's icon "lights up" the Favorites icon (if it exists), instead of appearing as a duplicate icon beneath the Favorites section on the sidebar menu.

Additional context

uname -a == "Linux ganymede 6.2.0-39-generic #40~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov 16 10:53:04 UTC 2 x86_64 x86_64 x86_64 GNU/Linux"

AppImages are an idea whose time has come. AppImageLauncher is the needed handler, and it needs a bit better handling of ambiguous situations, such as what I described here.