ivan-hc
`.desktop` files are not updated over time for the applications
They are only placed when installing the applications.
While they are rarely changing, it can happen that some fixes get introduced, like for StartupWMClass, maybe some new flag or environment variable is set or similar.
They should be also updated, likely by extracting the AppImage for .desktop & patching it for locations, similar to how it's done when installing.
When the scripts get updated am notifies that they changed.
adding this feature means making all the AM-updater scripts again, just too much technical debt lol
When the scripts get updated
amnotifies that they changed.
yeah, for install scripts that changed.
adding this feature means making all the
AM-updaterscripts again, just too much technical debt lol
yeah, but it would be good to solve this issue one day
yeah, but it would be good to solve this issue one day
Alright in that case it is better to make a new appimage template.
There is also another issue that we use --appimage-extract to get the ,desktop when there are methods to do it without --appimage-extract.
yeah, but it would be good to solve this issue one day
Alright in that case it is better to make a new appimage template.
There is also another issue that we use
--appimage-extractto get the,desktopwhen there are methods to do it without--appimage-extract.
there is a permissions issue: in AM you update apps in /opt without root, but to update a .desktop file, you have to edit /usr/local/share
there is a permissions issue: in AM you update apps in /opt without root, but to update a .desktop file, you have to edit /usr/local/share
Yes, that's a good point.
That means that chowning the desktop file would be also needed for update to happen without root.
I don't think chown is a viable solution, files in /usr/local should not be owned by a single user.
this is a separate issue that am has that Ivan is aware. Long ago I proposed to fix it by making a sudoers rule to allow updating without elevated rights but that never got anywhere. Ivan instead tried to do it with groups and that resulted in a catastrophe. lol
Ivan instead tried to do it with groups and that resulted in a catastrophe. lol
sad but true
I don't think
chownis a viable solution, files in/usr/localshould not be owned by a single user.
True
Long ago I proposed to fix it by making a sudoers rule to allow updating without elevated rights but that never got anywhere.
I can integrate sudoers file in my image, to test how it'll work.
Ivan instead tried to do it with groups and that resulted in a catastrophe. lol
sad but true
Still thinking how to solve that...
I found this and I wanted to point out that 'acestream' app leaves some .desktop files after removing the package. I think the main one dissapears, but the package seems to create up to 3 .desktop files in installation (for start/stop engine options) and not every single one of it are removed after uninstallation. Guess that might be a general issue with applications creating more than one .desktop file on install.
Would it be worth to create another ticket for this?
I found this and I wanted to point out that 'acestream' app leaves some .desktop files after removing the package. I think the main one dissapears, but the package seems to create up to 3 .desktop files in installation (for start/stop engine options) and not every single one of it are removed after uninstallation. Guess that might be a general issue with applications creating more than one .desktop file on install.
Would it be worth to create another ticket for this?
just tested and using am -HC acestream doesn't work on it, it keep instlling the .desktop files in my real $HOME, under ~/.local/share/applications
@xusism since the repository is on github (this is what I got with am -a acestream https://github.com/bro2020/acestream-appimage ) I suggest to contact the developer to fix this.
AppImages are not supposed to behave like this, but it is the developer's choice how to package the programs, so it is his responsibility.
I suggest to open an issue in his repository and ask him to remove this thing.
Anyway... is it the real owner of the program? Or just a third-party packager like us?
In both cases, there is no AppImage package that is not replaceable in this database. Also mainstream ones, see Libreoffice.
@xusism since the repository is on github (this is what I got with
am -a acestreamhttps://github.com/bro2020/acestream-appimage ) I suggest to contact the developer to fix this.
Oh okay, I'll let them know, thanks. I use "appman install" by the way as I prefer to install apps in my user in case I want to migrate my /home partition, so ~/.local/share/applications is my path in this case, I don't know if behaviour should be very different.
I have a thought that some people would like to do some modifications to .desktop file.
To satisfy those people, I think that having something like .env file for .desktops would be great, like how it's used for uruntime.
I'm not sure on how would the implementation in code look like though.
Maybe we can give an advice to them to use that feature of uruntime, instead of manually editing the desktop file.
We've demonstrated on several occasions that it's possible to add changes to .desktop files if necessary by modifying the scripts. We've also demonstrated that it's possible to notify users that an app has undergone radical changes, again by modifying the scripts and prompting users to run am reinstall.
Moreover, if upstream decides to update the .desktop files (and note, not only the launchers, but also the icons could change), the current mechanism doesn't allow us to perform such updates in real time.
The only plausible solution is to develop a template that can do all this, and modify all the scripts in this database to adapt them to this flow.
Alternatively, a well-structured external database would be needed that can replace the existing one and manage these changes.
But remember: AM manages portable apps, which are therefore not tied to a fixed database. And it does so by prioritizing the common thread it seeks to create between upstream and the end user regarding bug reporting.
Portable apps aren't DEB, RPM, or Flatpak packages, which instead rely on a single centralized database. They are free to be moved and subject to direct changes from upstream, with all risks!
Lately, I've noticed several AppImages missing .desktop files due to upstream compilation errors. These errors are constantly monitored in the repository https://github.com/ivan-hc/amcheck, and given their magnitude, a centralized database with physical packages, not scripts, would be necessary, thus cutting ties with upstream. This is wrong!
It's much more complicated than it seems, and AM isn't designed to manage a database of physical packages, nor does it have the resources to do so.
Soar is already a step ahead of AM in this regard, even if it means cutting ties with upstream, which my project shouldn't do. Reporting bugs to upstream helps their projects grow.
I'll therefore limit myself to making changes to the scripts to indicate the need for reinstallation. Users will be the ones to report these changes. I'll have the opportunity to present a "symbolic" flag to apply to scripts for this purpose, for example:
# Revision 20250720
...on the bottom of the script. this is enough for am -u and am -s.
Updating individual components (launchers and icons), however, is neither planned nor feasible.
If you have any concrete suggestions on how to proceed, please let me know. Show me a plan, a template... any idea on how to proceed. We'll analyze it together.
Until then, there's no point in keeping this issue open.