Skip to content
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

How to ensure the AppImage reuses files extracted from first run? #31

Open
mdear opened this issue Feb 23, 2024 · 1 comment
Open

How to ensure the AppImage reuses files extracted from first run? #31

mdear opened this issue Feb 23, 2024 · 1 comment

Comments

@mdear
Copy link

mdear commented Feb 23, 2024

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$
@mdear
Copy link
Author

mdear commented Mar 3, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant