TheAssassin
Ask the user to uninstall a previous version of a package when installing an update (not AppImageUpdate)
Pre-submit checks
- [X] I checked for similar issues beforehand, but could not find any. I could not add my proposal to any existing issue.
- [X] 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
The new AppImageUpdate integration might be great, but I still need to find an application that takes advantage of it. My suggestion would be to ask the user if he wants to remove the previous versions of an installed package (if possible).
Proposed solution
A modal or something, just like now
Alternative solutions you considered
Manually remove an old version (really annoying)
Additional context
No response
It would be nice if existing shortcuts could be kept, pointing to the new version. Now every time I update a program I have to manually remove the old version, then manually remove shortcuts/favorites/etc and manually re-create them (in the right order, of course, lest the new one will be named "Xxx (1)"). That's...not nice, to put it mildly.
There is no reliable way to associate two AppImages that belong to the same application to one another. Just going by the name doesn't seem reliable enough.
Instead of forcing a replacement you could just check if some of the existing AppImages have the same name, and if they do then ask the user which one, if any, to replace. Ta-daa!
I totally agree with @m-sundman . This is what I had in mind: you could check the name and, if it matches, ask the user if he wants to replace the app or keep both.
I'm not sure that functionality is even within the scope of AppImageLauncher. That seems very software manager like. This is where other applications shine, which can be used in combination with AppImageLauncher...
Need to think about this. I hardly can maintain the current feature set time wise...
I'm not sure that functionality is even within the scope of AppImageLauncher. That seems very software manager like.
AppImageLauncher installs software, and that's even more "software manager like" than uninstalling software. Whatever software installs things should be able to upgrade and uninstall those things, too.
You seem to have a misconception there. AppImages are not installed. They're integrated. The different terminology is used for a reason. AppImages remain completely portable, they can be moved or copied around by the user, without root access etc. You further ignore the fact that AppImages do not have a relation between each other. There is no formal standard or specification that defines a reliable algorithm how to associate different versions of the same application. The Name is just an arbitrary value. It has never been meant to be used as a unique identifier. There are plenty of applications out there which use a generic name. One example that comes to my mind is Popsicle, the USB flasher from Pop! OS, where I contributed AppImage packaging. The appimagecraft.yml needs to insert the prefix Popsicle manually there, actually. I am aware of the naming problem, but many (novice) AppImage maintainers are not.
Software managers, like apt, snap and alike, have a concept both for "application" and "single package" (both are entities in the respective systems, have unique identifiers, and a one-to-many relationship defined), something the AppImage specification does not have. The surrounding infrastructure supports this. Most notably, the clients enforce these relations. Think about updating a package in apt. Same name, same application. A new version on the server leads to an upgrade.
In case of AppImageLauncher, with the integrated support of AppImageUpdate, there is already the option to remove the old version. Here, we can obviously presume that the new and old AppImages belong to each other. We do not have to compare values which were never meant for such use.
Just comparing two AppImages' desktop entry's Name does not come close to any of this. Collisions are handled because that makes total sense UX wise. Note that this does not assume a relationship between the AppImages. All AppImageLauncher does is make sure two applications (AppImage or not) using the same Name do not generate same-looking entries within the application launcher.
I hate to write this sentence, but... feel free to fork the application. The code is free software for a reason. You can implement your suggestion there if you like. I do not invest my rare free time into adding features which I am not convinced about. I elaborated on the reasons your suggestion does not meet quality standards and therefore is not considered a solution.
If you want something like this, you may go upstream (AppImage specification for instance) and request a concept of "applications" to complement the "packages" concept AppImages provide. Some sort of unique ID, ideally easy to extract, would do.
I totally agree with you: if there isn't a standard naming scheme it can be quite tricky to integrate this feature. Unfortunately, not every app integrates AppImageUpdate properly: some do (like Postman, NoSQLBooster) some others (especially indie devs publishing on github) don't.
I ended up having 3 or 4 versions of the same app installed 😅.
I hate to write this sentence, but... feel free to fork the application. The code is free software for a reason. You can implement your suggestion there if you like. I do not invest my rare free time into adding features which I am not convinced about. I elaborated on the reasons your suggestion does not meet quality standards and therefore is not considered a solution.
I would really like to, but open source doesn't really mean anyone can implement the features he like. I don't know C and its functionalities, I would have to re-write everything in a language I know before I can even attempt something. That's why I opened this in the first place.
Btw more and more apps are implementing AppImageUpdate these days, maybe there is less need for a feature like this.
What we really need to blame is the poor integration that AppImages have by default with most Distros. A tool like this should be installed by default.
Anyway, thanks a lot for your replies and your time! I am closing this.
I would really like to, but open source doesn't really mean anyone can implement the features he like. I don't know C and its functionalities, I would have to re-write everything in a language I know before I can even attempt something. That's why I opened this in the first place.
@mijorus that sentence wasn't really directed to you, sorry if you had that impression.
Let's keep this issue open. It's a good idea IMO, just lacking a technically clean solution.
What we really need to blame is the poor integration that AppImages have by default with most Distros. A tool like this should be installed by default.
I agree. Just a dialog which asks users to make ELFs executable when they're launched through the file browser would be a great start already...
ultimately, what we need is a default folder where we can drop an .appimage an it will be automatically """""installed""""", just like it happens on MacOS.
AppImageLauncher makes it even easier with that modal.
You seem to have a misconception there. AppImages are not installed. They're integrated.
Apologies for using the term "install" loosely. I'm happy to use the term "integrate" instead of "install". So, whatever software integrates things should be able to reintegrate (ok, that's a bad term for sure :rofl:) and unintegrate those things, too.
Just comparing two AppImages' desktop entry's
Namedoes not come close to any of this. Collisions are handled because that makes total sense UX wise. Note that this does not assume a relationship between the AppImages. All AppImageLauncher does is make sure two applications (AppImage or not) using the sameNamedo not generate same-looking entries within the application launcher.
I completely understand that, but I'm not advocating for an automatic system like apt. I'm just saying that if it can detect the name clash, then instead of just assuming the user wants another AppImage with the same desktop entry name added, using a counter (like "... (1)") to distinguish them, it might as well ask if the user might want to replace (one of) the existing one(s) instead of that automatic "...(1)" thing. No automatic decision-making there. Nothing like apt. Just ask the user what they want to do. All the functionality is already there, is it not? I mean, it can obviously detect the name clash, and it knows how to "unintegrate" the other AppImage, right? Is something else needed?