New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feature request]: Provide ability to create/update symbolic link to target #153
Comments
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 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? |
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
Additionally, because I'm intentionally running development versions I want to have control over when applications update, so something like |
Same here. What would be the advantage of what you are suggesting over doing manually, say,
? |
Well, that's basically what I'm doing now, only by hand:
Right now the tool doesn't give me the name of the resulting file so that I can automate this my own way. |
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. |
/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:
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. |
AppImageLauncher has been updated and doesn't require any workarounds any more, if that's what you mean with stability. See TheAssassin/AppImageLauncher#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.
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.
Which tool? AppImageUpdate? The official CLI appimageupdatetool that provides even a few features not included in the GUI version. |
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 Having downloaded *: 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. |
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 anx.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:
It would be nice if I could do the following:
and have the resulting output:
Thus, as a user, I can create a
.desktop
file which references the symbolic link and make my overall workflow more streamlined.The text was updated successfully, but these errors were encountered: