allow runtime control of the automatic updater

[henning-schild]

Steps to reproduce

1. install any version of tdesktop, i.e. using gentoo portage
2. wait for the next release
3. and wait for your HOME and that of all other users of the machine to be filled up with updates
4. now the package manager installs that update again ...

Expected behaviour

When tdesktop (the pre-compiled version) is packaged by a distro, users expect their package manager to control potential updates.

Actual behaviour

The client will update itself for many users on the machine before the distro package maintainers can ship an updated package. The application will be installed many times.

Configuration

Linux

Version of Telegram Desktop:
any version

Used theme:
any theme

Could we introduce an environment variable or argument to prevent the auto-updater by default? Distros - like gentoo - package tdesktop in a timely manner and the auto-update defeats the package manager, filling up the HOMEs of the users for no good reason.

https://bugs.gentoo.org/618662

The real discussion would be to drop the Qt patching and allow for dynamic linking, but that has been discussed/rejected elsewhere. As a mitigation i suggest allowing people to package the pre-compiled binaries in a way that plays nicely with package managers.

[asarubbo]

I'm the person who filed the downstream bug.
By summarizing I have installed telegram for our package manager and I was able to update it from the gui. So at some point the package manager says that the version installed is X while was Y.

I'm sure that it is not an elegant solution, but can the updater be inhibited if there is a file called "noupdate" somewhere?

[henning-schild]

A global config file would be even better than an environment variable or argument. No need to wrap the binary with a script and no risk for it to be called without the wrapper.

[john-preston]

Perhaps I could emulate TDESKTOP_DISABLE_AUTOUPDATE macro definition in case of finding "noupdate" file in "[DataPath]/tdata/" (on Linux it almost should be ~/.local/share/TelegramDesktop/tdata).

[henning-schild]

@john-preston it needs to be a global location so that a package can ship this file without having knowledge about who (which ~) will run it later on

[john-preston]

@henning-schild If a custom build (with TDESKTOP_DISABLE_AUTOUPDATE being set) is not an option then I guess only a command line argument is left. I don't like the idea that official binary, downloaded from site and unpacked somewhere non-write-protected won't update itself :(

[asarubbo]

@john-preston what about telegram checking if is possible to run the update from something like /etc/tdesktop/tdesktop.conf ?

The official binary package won't have such file but in the packaging phase we will add such file.

[john-preston]

@asarubbo I meant that the from-site version won't be able to autoupdate if a package version was installed in that system. I'm not sure this is good.

[henning-schild]

@john-preston to me it seems that you see the issue and want to help out, Thanks!

I see your point, if the packages do not get updated you loose control over when people get their updates. The only thing i can say about that is that you will need to trust those distros to update the package when a new version is released. That is not much different to accepting that people could disable the updates, just on a larger scale.

Not having control over which versions are shipped in distros is a common "problem" for every project. But users of those distros also expect their package maintainers to decide what is installed, not the packages auto-updating themselfs. I can only speak about gentoo, where i maintain tdesktop. It has always been updated a few hours/days after the releases. And where several users complained about the package updating itself behind the back of the package manager.

[john-preston]

@henning-schild So a command line argument is not a good solution?

[henning-schild]

@john-preston a command line argument would be fine, in that case a distro would ship a wrapper to always call the binary with that option

[henning-schild]

@john-preston sweet, thanks!

gentoo/gentoo#9218

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.