Feature Request: Enable ability for downstreams to disable upgrade checking.

[JoshStrobl]

The Issue

As a package maintainer for a downstream Linux operating system (Solus), I'd prefer to directly provide users with an upgraded package which respects our routine syncs to our stable repo, ensures that such app upgrades won't negatively impact users, and alleviates any concerns on my part about unexpected behavior being reported to us for changes that may occur (such as a gained dependency that isn't installed on the user's system).

Currently, the LBRY app runs a check in src/renderer/redux/actions/app.js to see if an upgrade is available and subscribes to checks, however this is limited to a user-set disabling to skip an upgrade.

Ideally, I'd like an option as a downstream to disable upgrade checking entirely, even if it's via an option with yarn. Currently I've opted to just patch out (with some overkill) update checking but would obviously like a more official solution.

Acceptance Criteria

1. 2. 3.

Definition of Done

• [ ] Tested against acceptance criteria
• [ ] Tested against the assumptions of the user story
• [ ] The project builds without errors
• [ ] Unit tests are written and passing
• [ ] Tests on devices/browsers listed in the issue have passed
• [ ] QA performed & issues resolved
• [ ] Refactoring completed
• [ ] Any configuration or build changes documented
• [ ] Documentation updated
• [ ] Peer Code Review performed

[kauffj]

Thanks @JoshStrobl! I strongly suspect we can accommodate this. Maybe one for @IGassmann?

[alexliebowitz]

I just saw this (missed the message in Slack from Wednesday)

In the new upgrades PR, there are two places in main/index.js where it's checking for upgrades (one check for Linux using the old system, and one using electron-updater on Win/Mac). This should be super easy for either me or @IGassmann, but we just need to make sure it's changed in both places.

[JoshStrobl]

Just an update on this, it's gotten progressively harder to patch out auto updating / upgrading as of 0.20.0. I'm having to remove entire modals, set various variables to false (like src/main/index.js autoUpdater.autoDownload to false).

[kauffj]

@JoshStrobl does AppImage or Flatpak make this any better for you?

[JoshStrobl]

It would not, as we ship lbry-app in our repository, with it leveraging our optimized nodejs (we'd lose out on those optimizations with AppImage or Flatpak), packaged and versioned build tooling like yarn, and with plans on expanding LBRY support by packaging and maintaining lbry to enable the use and running of the lbry blockchain without the need to run the app itself (this enablement will be done via systemd units).

Even if I could just set a global variable or a runtime flag (and just have a patched desktop file) that'd be immensely helpful.

[kauffj]

@IGassmann is rapidly becoming the build expert. If this is as simple as a packaging flag to disable auto-update, I suspect this is something we'd be happy to accommodate.

[JoshStrobl]

So I really hate to necro tasks and apologies in advance for doing so, but I feel the need to do it on this one as it is becoming progressively more difficult to maintain LBRY Desktop downstream in Solus as a result of the repeated redesigns and re-architecture of the app, necessitating the rebasing of patching (which has needed to also be more intrusive across newer releases, really ramping up in 0.34). Currently, my patch has to modify 9 files (listed below), with 7 insertions (package.json changes to force x64 architecture compilation, otherwise arm and i386 libs from Electron get into the package) and 248 deletions:

• src/ui/component/page/view.jsx
• src/ui/component/splash/view.jsx
• src/ui/index.jsx
• src/ui/modal/modalAutoUpdateConfirm/index.js
• .../modal/modalAutoUpdateDownloaded/index.js
• src/ui/modal/modalDownloading/index.js
• src/ui/modal/modalRouter/view.jsx
• src/ui/redux/actions/app.js
• src/ui/redux/selectors/app.js

I've ended up stripping out the doAutoUpdate+doAutoUpdateDeclined modals, removing update-downloaded signals, removing the various buttons and logic around that, stripping out case MODALS references for UPGRADE and AUTO_UPDATE_DOWNLOADED, stripping out intervals and checking, stripping out skip upgrade functionality, etc. You can see all of this at https://dev.getsol.us/source/lbry-app/browse/master/files/0001-Force-x64-and-strip-out-upgrade-prompting.patch

As a result, it is more time consuming for me to update LBRY Desktop for Solus to make it available to LBRY users on our operating system (including myself), resulting in delayed delivering of updates (new features, SDK changes, etc.) which is additionally more problematic since it has to compete with other software I maintain as well, so it typically ends up as a lower priority item and just "something I'll update when I get the time". Case in point, we're still on 0.35.3 despite the fact it was released almost 3 weeks ago, as a result of me having to update our GNOME Stack and focus on other user issues.

I would greatly appreciate if there was some movement on this issue, even if was just a CLI option I had to pass in our desktop file to the lbry executable to disable updating and update checking. Otherwise LBRY on Solus runs the risk of being deprecated from the repo with no obvious way for users to get the latest release (we are built from scratch, don't support the pre-built Debian packages, the community built Flatpak is just as outdated, and no snaps are provided by LBRY). I really don't want to do that as I personally want to continue using + consuming content via LBRY, but I also don't want our users being provided a potentially outdated LBRY Desktop experience either.

[kauffj]

@JoshStrobl necro'ing tasks is perfectly acceptable (preferred even) since it let's us know that an issue still exists.

If all the upgrade behavior was behind a process.env check, would you be able to set that in your builds for Solus? Or do you have another opinion or suggestion as to how to toggle this flag in your build?

[JoshStrobl]

@kauffj It being put behind process.env should be a viable solution if launching from a GUI, as I'm able to utilize the Desktop File specification's exec + env support (so like Exec=env DISABLE_UPDATER=1 lbry as an example), however it wouldn't solve any cases of it being launched from the CLI (doubtful that is a common usecase so not sure how much of a concern that'd be).

An alternative solution could be checking if a specific file exists on the system in a system-wide directory (as opposed to in the user's home directory, since most packaging systems don't support the shipping of files that manipulate a user's home dir for safety reasons), which would solve it for GUI and CLI purposes since that could be shipped in the package itself. Up to you folks :slightly_smiling_face:

[kauffj]

@JoshStrobl hard-checking for a file on disk is a viable solution with a low time cost. I don't see why we couldn't do that. We've got to get through this upcoming release + lbry.tv release (which are basically the same release), but I'll see if we can get this in in the release behind that one.

[neb-b]

Added in #3206!