[feature request]: Provide ability to create/update symbolic link to target

[brianredbeard]

As a user, I think of an application as a single monolithic set libraries and executables. By all accounts, it seems that this worldview is in alignment with the idea of AppImages.

When I attempt to execute an application the minor version information is unimportant to me (i.e. the .y.z in an x.y.z semantic version).

It would be ideal if (at a minimum) the update tooling (i.e. appimageupdatetool) could provide the ability to specify a symbolic link which should act as a pointer to the the updated binary.

Providing the user the mechanism to specify the name (or full path) to the link may also aid in situations where users desire to maintain "development" and "stable" copies.

Example:

I presently have the following binaries:

FreeCAD_0.19-21775-Linux-Conda_glibc2.12-x86_64.AppImage
FreeCAD_0.19-22039-Linux-Conda_glibc2.12-x86_64.AppImage
FreeCAD_0.19-22039-Linux-Conda_glibc2.12-x86_64.AppImage.zs-old
FreeCAD_0.19-22262-Linux-Conda_glibc2.12-x86_64.AppImage

It would be nice if I could do the following:

./appimageupdatetool-x86_64.AppImage --link FreeCAD-0.19-development FreeCAD_0.19-22039-Linux-Conda_glibc2.12-x86_64.AppImage

and have the resulting output:

FreeCAD-0.19-development ⇒ FreeCAD_0.19-22039-Linux-Conda_glibc2.12-x86_64.AppImage

Thus, as a user, I can create a .desktop file which references the symbolic link and make my overall workflow more streamlined.

[probonopd]

Hi @redbeard and welcome to AppImage!

So to get to the underlying motivation, it seems like you are looking for an easy way to have a desktop file that always points to the latest version? I am asking because I am thinking about implementing this behavior in go-appimage's appimaged.

What I envision, though, would work a bit differently: The desktop file would call appimaged which in turn would launch the latest version known to it on the system.

Would that satisfy your needs?

[brianredbeard]

Sorry for the delay. I think it could be functionally the same thing. To be fair I have an odd workflow anyways, so I was trying to suggest something that would be useful for more folks than myself.

Personally (with a few exceptions) I normally don't use .desktop files:

• I'm largely keyboard driven and that would add extra work by forcing me to prepend xdg-open.
• I am normally running development versions of applications, because I'm OK with crashes and want to make sure I capture logs for opening bugs.

Additionally, because I'm intentionally running development versions I want to have control over when applications update, so something like appimaged isn't really something I would use. I think that is good functionality for folks to have as I would contend that the "average" user doesn't really care and would prefer to have everything be current without additional burden.

[probonopd]

I'm intentionally running development versions I want to have control over when applications update, so something like appimaged isn't really something I would use.

Same here. appimaged does not auto update, and when you choose to manually update an app, you got to keep both versions.

What would be the advantage of what you are suggesting over doing manually, say,

sudo ln -s FreeCAD_0.19-22039-Linux-Conda_glibc2.12-x86_64.AppImage /usr/local/bin/freecad-dev

?

[brianredbeard]

Well, that's basically what I'm doing now, only by hand:

[~]$ cat ~/.local/bin/upgrade_freecad.sh 
#!/bin/bash -l

set -eu -o pipefail 

APPLICATION_LINK="${HOME}/Downloads/FreeCAD-0.19-development"

LOCATION="$(readlink -f ${APPLICATION_LINK})"

cd "$(dirname ${APPLICATION_LINK})"

~/Downloads/AppImageUpdate-x86_64.AppImage "${LOCATION}"
# Manually go find the new binary by digging through stdout of the application
#  or quickly running "ls -ltr | tail -n1"

#ln -sf -T ~/.local/bin/${BINARY}-${VERSION} ~/.local/bin/${BINARY}

Right now the tool doesn't give me the name of the resulting file so that I can automate this my own way.

[probonopd]

Is there anything that you think could be accomplished better if it was part of e.g., AppImageUpdate? We want to keep the AppImage runtime (the code that is part of each AppImage) as minimalistic as possible.

[brianredbeard]

/me sighs

Honestly.... the deeper i go into this the more annoyed I get. Hypothetically, through it's use of AppImage, FreeCAD should be able to self-update. That being said, between:

• the lack of stability with the internal updater in FreeCAD
• the GUI focus of this tool
• the fact that I've never been able to get AppImageCrafters/appimage-manager nor AppImageCrafters/appimage-update to work

I just think I'm not the target audience of any of this (which is completely OK). This has just turned into literal days of lost time testing different paths, reading documentation and code, debugging, etc and it's just not at all related to the problems I'm really trying to solve.

At this point I'm going to just close out the issue so that the tracking and backlog grooming can be kept accurate while allowing for the next time traveler to find this, (hopefully) cite it, and provide better feedback around needs.

Thanks for the effort around this though. I look forward to looping back in the future and checking in.

[TheAssassin]

the lack of stability with the internal updater in FreeCAD

AppImageLauncher has been updated and doesn't require any workarounds any more, if that's what you mean with stability. See https://github.com/TheAssassin/AppImageLauncher/issues/361.

This updater bridge stuff is non-official code (doesn't even use the official updater library, see below). If there's bugs, you need to talk to its dev.

the fact that I've never been able to get AppImageCrafters/appimage-manager nor AppImageCrafters/appimage-update to work

https://github.com/AppImage/AppImageUpdate is the one and only official solution, which also provides a library called libappimageupdate (that also provides a Qt frontend) which can be embedded in other tools (the most famous example being AppImageLauncher, where it's the basis of a tiny updating tool that is merely a wrapper around that library). Third party tools might not work as intended, and won't be supported by the AppImage team.

the GUI focus of this tool

Which tool? AppImageUpdate? The official CLI appimageupdatetool that provides even a few features not included in the GUI version.

[brianredbeard]

Currently the internal updater in FreeCAD is completely broken:

It's totally understood that tooling shipped outside of the core ecosystem is outside of the control of the core maintainers. I mention them because the only reason I even found them was because of https://github.com/AppImage/awesome-appimage. I was looking for a CLI based update mechanism. Within the README.md on this repo there isn't mention of the CLI tool specifically or differentiation between AppImageUpdate and appimageupdatetool. I'd say there's an opportunity there to clarify things. Additionally, as most of the wiki's on GitHub are empty (and that the project links to https://appimage.org/ in it's description) it didn't dawn on me to look for specific documentation in the wiki*. That is clearly a deficiency on my part.

Having downloaded appimageupdatetool, reviewed it for the use cases in my previous comments, and reflecting on @probonopd question about improvements to this tooling the main thing I would request is the ability to retrieve the filename which is to be written in some structured way. This would then allow for that data to be used in other scripted tooling.

*: To be fair, it is ironic that in the wiki article it states: "AppImages seem to work even when called via symbolic links!" given the initial request in this issue.

[TheAssassin]

*: To be fair, it is ironic that in the wiki article it states: "AppImages seem to work even when called via symbolic links!" given the initial request in this issue.

Looking at the context, this statement explicitly refers to the fact that appimageupdatetool can be called through a symlink. It doesn't discuss whether symlinked AppImages can be updated with a single word.

The page was also written by a contributor (arguably, nobody expects you to know that). Also, it is quite old and contains a warning that it is incomplete. It's not any form of official documentation.

Edit: This is also the reason why I don't think embedding any form of software that works with the AppImage itself (like updating, but also desktop integration and many more things) is a good idea. For desktop integration, this is already an established best practice. We should consider discouraging people from embedding updating technology as well.