You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apaprently, if the NO_CLEANUP env variable is set, the AppImage infrastructure is supposed to not remove the unpacked files and reuse the existing files.
This is really important as we aim to use AppImage packaging in production deployments where we could manage a single unpacking delay, but do not want this delay each and every time the AppImage is run.
Why does this feature appear not to work?
I did try to build the appimagetool from the latest git repo, but still have not yet succeeded in doing so, so I took latest released binaries.
foot@qemuarm64:/home/ccs/Qt/Projects/CortexBuilds/bin# ./linuxdeploy-aarch64.AppImage --version
linuxdeploy version 1-alpha (git commit ID 2b73a21), <local dev build> built on 2024-02-12 13:22:56 UTC
root@qemuarm64:/home/ccs/Qt/Projects/CortexBuilds/bin# ./linuxdeploy-plugin-appimage --version
Failed to parse arguments: Flag could not be matched: version
./linuxdeploy-plugin-appimage {OPTIONS}
linuxdeploy-plugin-appimage
OPTIONS:
--appdir=[AppDir] AppDir to package as AppImage
--plugin-type Return plugin type and exit
--plugin-api-version Return plugin type and exit
root@qemuarm64:/home/ccs/Qt/Projects/CortexBuilds/bin# ./linuxdeploy-plugin-qt-aarch64.AppImage --version
./linuxdeploy-plugin-qt-aarch64.AppImage {OPTIONS}
linuxdeploy Qt plugin
OPTIONS:
--appdir=[appdir path] Path to an existing AppDir
-p[plugin...],
--extra-plugin=[plugin...] Extra Qt plugin to deploy (specified by
name, filename or path)
--plugin-type Print plugin type and exit
--plugin-api-version Print plugin API version and exit
--plugin-version Print plugin version and exit
Bundles Qt resources. For use with an existing AppDir, created by
linuxdeploy.
root@qemuarm64:/home/ccs/Qt/Projects/CortexBuilds/bin# ./appimagetool --version
appimagetool, continuous build (commit 8bbf694), build <local dev build> built on 2020-12-31 11:48:29 UTC
root@qemuarm64:/home/ccs/Qt/Projects/CortexBuilds/bin#
ccs@v700:~/Downloads$ export NO_CLEANUP=1
ccs@v700:~/Downloads$ sudo ./Dice-aarch64.AppImage
/tmp/.mount_Dice-a5QqLk2/AppRun.wrapped: error while loading shared libraries: libglapi.so.0: cannot open shared object file: No such file or directory
ccs@v700:~/Downloads$ ls /tmp/.mount*
ls: cannot access '/tmp/.mount*': No such file or directory
ccs@v700:~/Downloads$
The text was updated successfully, but these errors were encountered:
I have since resolved the errors shown in the last snippet, yet still observe that even though I can run my AppImage successfully on my ARMv8 target the temporary directory was removed despite setting of the indicated env variable.
Since I see the AppImage unpacks to volatile (likely ephemeral) storage, I considered but ultimately rejected a workaround, reasons given below:
Given that I want the flexibility of an AppImage but the persistence of a locally installed app,
Given that the extraction of the AppImage to volatile storage on our ARMv8 platform based on Yocto Poky Linux appears to be done relatively quickly
Given that our users need the app running as soon as possible after reboot
The benefit to extracting to nonvolatile storage via the --appimage-extract option and copying into volatile storage for runtime efficiency on every reboot may not be an effective strategy, we may end up just launching the AppImage on startup and letting itself unpack to volatile fast working storage every time.
Apaprently, if the NO_CLEANUP env variable is set, the AppImage infrastructure is supposed to not remove the unpacked files and reuse the existing files.
This is really important as we aim to use AppImage packaging in production deployments where we could manage a single unpacking delay, but do not want this delay each and every time the AppImage is run.
Why does this feature appear not to work?
I did try to build the appimagetool from the latest git repo, but still have not yet succeeded in doing so, so I took latest released binaries.
The text was updated successfully, but these errors were encountered: