Dependencies on Steam Deck need to be Manually Updated

[sonic2kk]

System Information

• SteamTinkerLaunch version: v12.0
• Distribution: SteamOS
• Installation Method: Manual

Issue Description

Dependencies on Steam Deck do not automatically update. This is not a major problem as a user can simply reinstall SteamTinkerLaunch and the issue should be resolved.

Dependency versions are usually not a problem, but some like innoextract need to be bumped when SteamOS gets rebased on a newer Arch snapshot. It seems like based on #716 that dependencies do not automatically update, which is something I never even considered before. Not sure how it slipped my mind.

I am not sure of the best way to handle updating these dependencies to be honest. For now, the fix path is to simply reinstall SteamTinkerLaunch clean by clearing out ~/stl and reinstalling. Very straightforward (especially with ProtonUp-Qt), but not documented until now I guess and also not ideal.

Logs

N/A.

[sonic2kk]

I wonder if it would be possible to simply do a --version check. I think most of the binaries we would download would allow for this. I know innoextract supports it, it returns a string like innoextract X.X. We could just grep this and remove the innoextract part, and then check the version. If the output of that command is different than the version we have, we can remove it.

Maybe this should be a separate check, then if the version of the dependency doesn't match we can remove it and then we don't have to duplicate any downloading code.

I will look into this soon and hopefully if this idea works it should be fixed soon.

[frostworx]

There is already an innoextract version check.

[sonic2kk]

Ah! I think this is in the MO2 installer section, which is fine. However the version problem is because of a minor version change. It's not going from 1.8 to 1.9, it went from 1.9-5 (iirc) to 1.9-7 for SteamOS 3.4.

However thinking about it again I don't think innoextract --version returns those sorts of "rebuild" versions, since I think they're distro-specific.

[frostworx]

the few lines could be easily called from everywhere of course, but true, upstream versions never contain the package management version string, so this won't help here.
the only option is to automatically check upstream for a newer version and compare it with the built-in one
(imho It would make sense to migrate the built-in one into global.conf then and also add an option for an auto-bump)

wget -q https://archive.archlinux.org/packages/i/innoextract/ -O - | grep "^<a href*.*zst<" | sort -V | gawk -F'-' '{print $2"-"$3}' | tail -n1

currently returns 1.9-7 so the function would return a nothing to do.

please let me know if you need help for a proper implementation and I'll find the time.

[sonic2kk]

Thanks! That line should work, I'll try and implement this soon :-)

[sonic2kk]

Have a good idea on how I want to implement this, basically what I outlined here + the package manager version snippet provided. Time has been a bit thin this month (January is busy 😅) but I am hoping to find time to get it finished before the end of the week.

I will keep it on a separate branch and extensively test on my own Steam Deck to make sure nothing gets broken before merging to master.

[juan-90s]

I found the MO2 cannot start after some steamdeck system packages update. I clear out the stl file and reinstall it. MO2 still cannot be installed and started.

INFO - installMO2 - Installing '/home/deck/.config/steamtinkerlaunch/downloads/mo2/Mod.Organizer-2.4.4.exe' into '/home/deck/.local/share/Steam/steamapps/compatdata/489830/pfx'
ERROR - installMO2 - Version for 'innoextract' is invalid. You need to at least version '1.9'
ERROR - installMO2 - Starting /home/deck/.local/share/Steam/steamapps/compatdata/489830/pfx/drive_c/Modding/MO2/ModOrganizer.exe using wine/proton instead
WARN - installMO2 - Unfortunately 'innoextract' is required to install ModOrganizer on the Steam Deck, but it wasn't found

This problem is related to this issue i think. Hope a solution will come.

[sonic2kk]

Looks like you don't have innoextract at all, so no this isn't related. It tells you in your log, Unfortunately 'innoextract' is required to install ModOrganizer on the Steam Deck, but it wasn't found.

I suggest reinstalling SteamTinkerLaunch and then ensuring you have innoextract at ~/stl/deps/usr/bin.

If you have network issues that prevent you from downloading some Steam Deck dependencies, you can install innoextract 1.9-7 manually from the Arch mirrors. No solution will come for this issue you described as this is a configuration issue and not related to automatic updating.

[juan-90s]

I suggest reinstalling SteamTinkerLaunch and then ensuring you have innoextract at ~/stl/deps/usr/bin.

I checked. I already have the innoextract there.
the MD5 of that is 6ea8a4326adfc1f37eb4290c849060

Update: this file is incorrect. Fully reinstalling STL is needed.

[sonic2kk]

If you've already tried reinstalling including removing the dependency and reinstalling it, then you'll have to open a new issue.

[sonic2kk]

Make sure you have fully removed SteamTinkerLaunch from ~/stl and reinstalled, and also make sure you have tried manually updating innoextract, before you open an issue.

[sonic2kk]

So upon thinking for a few days on this I came to realise that automatic updates, strictly speaking, are not really the way to go. We want to automatically update to the version that SteamTinkerLaunch expects - That is, if SteamTinkerLaunch expects 1.9-7, we want to automatically update to that version instead of the latest available.

This is because the latest available can have incompatibilities, for example innoextract 1.9-5 was required on SteamOS 3.3.3, but innoextract 1.9-7 is required on SteamOS 3.4. I can see a case where, say, innoextract 1.9-8 comes out and may be required on desktop, but may be incompatible with the older Arch snapshot that SteamOS 3.4 is based on.

Therefore we want to stick to defining a fixed version of the dependencies, then we'll compare the last downloaded version written out to a text file with the version that SteamTinkerLaunch is expecting, and use that to dictate whether or not we need to update. If there is no version file written out, we'll assume we need to update.

Currently writing up a draft implementation. I'm going to try and test this significantly to make sure it doesn't break dependency downloading. Most of the Steam Deck installation code was refactored recently and how it works is fresh-ish in my mind so I am hoping nothing goes terribly wrong.

This feature should ideally not be used very often, probably only a few times a year at most. But for when it is used I want to make sure it works 😅

[sonic2kk]

The PR I previously opened is not a great go-forward approach imo. Perhaps we need a better way of generally managing dependencies on SteamOS. Open to suggestions and discussions (or contributions 😉)

[sonic2kk]

Note to future-self and anyone interested in looking into this: #736 (comment) has some hints around two tools:

• Conty
• Junest

The potential problem as noted in that comment with these tools is that these may require further dependencies to be managed as well, which wouldn't really fix anything 😅

Other suggestions on a better go-forward approach for managing dependencies on Steam Deck are welcome, as even though these bumps should only happen a couple of times a year, it would be nice to have a "clean" solution for this (somehow).

I have been looking into other things related to STL (and also been contributing non-STL work to ProtonUp-Qt), as well as actually using STL for gaming, so I have not had as much time for this issue. I will keep this open for the meantime though :-)

[sonic2kk]

SteamOS 3.5 is on the horizon with a newer kernel, I wonder how SteamTinkerLaunch will be impacted. We may have to roll a new very minor version e.g. "12.0.1" as I don't feel like making a release with the current changes (SLR fix is something I'm proud of but the GameScope features exposed are still very much limited to bleeding-edge GameScope, I'd rather give them some time to filter down).

[sonic2kk]

#854 gives a quicker stop-gap solution in the form of a command to clear the dependencies so they'll be re-installed on update. The rest of this proposal has been consolidated into #859, in the hope of inspiring some community contributions.