Problems with the self-updating implementation

[loathingKernel]

I think the self-update functionality in ULGWL is problematic, at least implemented into the same script that sets up the environment, for the following reasons

• It steps into the front-end territory instead of being a back-end solution. As ULWGL target is to be used by other clients, and most clients already have individual ways of downloading binaries, they are a better fit to download ULWGL and ULGWL-Proton releases. If a common file path location is desired, documentation might be a better way to do it. Hard-coding absolute paths into the script itself makes it less portable.

• If an update is required, it creates the long-standing operation of downloading the binaries that GUI clients have very few ways to keep track of and notify the users about. You have to either show a very vague busy spinner while the download is happening, or parse the output of wget to show something meaningful. There are people like myself who only have access to very slow internet connections, making the process require significant time.

• It needlessly complicates the script that should just set up the correct environment. As the self-update functionality is something that can be useful if it use from CLI, I suggest to be split into a separate script that can be installed as /app/bin/ulwgl-run, that wraps around the real ulgwl-run in "$HOME"/.local/share/ULGWL, providing it with PROTONPATH if it wasn't configured.

• Make development harder as it tries to download things already available in the local directory into $HOME/.local/share/ULGWL

If this is desired, I can make the modifications and open a PR.

[GloriousEggroll]

Agreed here, as long as it still works in flatpak I'm for the approach. My implementation was a crude "make it work" start.

[R1kaB3rN]

I agree with all your points and I believe that we should just keep it simple and just remove this functionality as we have better options for handling updates. For instance, we can simply push updates to Flathub or leave it to distributors to build from source and ship them. On Arch, a PKGBUILD would be relatively straightforward to define as it would be pretty much be similar to WINE or Steam's dependencies. Given these options, I'm curious of the rationale for the self-update functionality, unless this is a feature requested from users?

If we ship updates this way, we can also satisfy the implicit dependencies required by the CLI for users. Currently, Steam's container runtime cannot bundle some libraries such as 32-bit glibc or 32-bit Mesa, so not all games will work for them unless they have them installed.

[GloriousEggroll]

I agree with all your points and I believe that we should just keep it simple and just remove this functionality as we have better options for handling updates. For instance, we can simply push updates to Flathub or leave it to distributors to build from source and ship them. On Arch, a PKGBUILD would be relatively straightforward to define as it would be pretty much be similar to WINE or Steam's dependencies. Given these options, I'm curious of the rationale for the self-update functionality, unless this is a feature requested from users?

If we ship updates this way, we can also satisfy the implicit dependencies required by the CLI for users. Currently, Steam's container runtime cannot bundle some libraries such as 32-bit glibc or 32-bit Mesa, so not all games will work for them unless they have them installed.

We can't do that on flathub, at least not with installation to ~/.local/share, which is preferred. The reason we install to ~/.local/share is the same reason valve does. When the runtime runs it needs to create its own var folder that it reads/writes to, you can only do that in ~/.local/share.

In steam flatpak, it downloads the Steam Runtime to ~/.local/share/steam/steamapps/common/, which is why it works. steam is the main process while the runtime is running from the user's ~/.local/share folder.

Ideally ULWGL should work the same way, a main process called from /usr/bin, which calls the ulwgl-run script from the ~/.local/share/ULWGL/ folder.

Right now the ulwgl-run script in /usr/bin in the flatpak is just a copy of the one in the ULWGL folder since it double to both run the runtime and update it -- which is as discussed a crude way to handle things

[GloriousEggroll]

I merged #17 but I'm leaving this open for discussion as to whether or not we want this in the pending launcher rewrite

[loathingKernel]

Agreed. It was partly the intention with creating #17 that it would also unblock the rewrite to not get delayed further with updates.

[GloriousEggroll]

just noting final intentions here since it was brought up again in #29

We -do- want ULWGL-Proton to get downloaded regardless of flatpak or normal in the event that the user does not have a Proton version specified or installed. We need this as a fallback to ensure protonfixes get applied.

For this basically -- we need to move the ULWGL-Proton auto-downloading to the ulwgl-run script. @R1kaB3rN

We -do not- want ULWGL-launcher to get auto-updated.

For this what we want to do is update the flatpak to store the ULWGL-launcher files in apps/share (or /usr/share for non-flatpak), then /usr/bin/ulwgl-run-cli should just copy them into ~/.local/share/ULWGL. This will allow us to keep proper versioning both in flatpack and distro packaging. I can handle this part

[loathingKernel]

Could we direct users to the update script through docentation or installing it in the PATH as ulwgl-run, like flatpak does, instead of doing it in the internal script? My worry is that if it is in the internal script, it is one typo away from downloading the proton version, giving the false impression that it takes too long or that it works when it shouldn't.

[GloriousEggroll]

we can simply implement a zenity popup and/or text noting it's downloading.

The problem with putting ulwgl-run-cli in /usr/bin is that launchers are calling ulwgl-run from the ~/.local/share/ location which means they would skip downloading a version. Thats fine for launchers that already define a proton version, but not great for those that dont

[GloriousEggroll]

Or we could add a popup that says "A proton version was not specified, would you like to download the latest ULWGL-Proton version?" then have the ulwgl-run script call the downloader script and/or download directly

[loathingKernel]

I see, I understand the plan now. This is a reasonable solution.

[GloriousEggroll]

closing as resolved per #30 and a11eef7

[GloriousEggroll]

Opening this part:
Or we could add a popup that says "A proton version was not specified, would you like to download the latest ULWGL-Proton version?" then have the ulwgl-run script call the downloader script and/or download directly

As separate issue