fix: disable update on linux

[daiyam]

Hi,

This PR is disabling the update check on linux.
Unlike macOS or Windows, there is no automatic update. When an update available, it's redirecting to the .tar.gz however it was installed.
Most users would have installed VSCodium with a package manager. In that case, the update check isn't needed. And it will most likely be in conflict with the package manager. (download .tar.gz instead of showing the package manager)
If the user have install it directly from the .tar.gz, .rpm or .deb, it will need to check manually for an update. I think it should be fine for any power user.

@paulcarroty @GitMensch @geekley @DanielProg39 @mndscp @evur Could I have your opinion? Thx

[paulcarroty]

LGTM.

[GitMensch]

i think this is only the default that is changed and people can opt in later (on that case the wiki should have a note), so this is fine for me.

If they need to enable it by file, then it should be documented for the users - or, maybe better, be left as is and submitted as a patch to the distros (I think most would have disabled that already, no?).

[GitMensch]

Note: one thing that may be missing (or I've overlooked it) is a "complete" source package download (all source + patches applied).

[DanielProg39]

@daiyam Totally agree. Whether I'm using flatpak, deb or rpm, I get updates automatically from the appropriate repository, so there's no point in checking for updates, because in Linux checking and installing updates is a job of the package manager.

[geekley]

Makes sense to me. My settings already have "update.mode": "manual" anyways -- exactly because I don't wanna worry about it doing something weird because of a "double update" conflict or whatever.

[mdickopp]

Is there a setting or some other way to get the old behavior back?

[GitMensch]

That's only the default, therefore you should be able to opt in with the user settings (where you previously could have opted out).

[daiyam]

No, the update process has been completely disabled on Linux.

[daiyam]

@mdickopp How to do you install VSCodium?

[mdickopp]

@daiyam I just unpack the tar.gz file.

Is there any chance that the update check will be restored?

[daiyam]

The current .tar.gz will keep the updates disabled since most users use a package manager to install the VSCodium.
This is to avoid the conflict between the updates processes (from the manager and VSCodium). It's due to that those managers are using the .tar.gz as their source (we are also doing it).
I made the conscious choice that power users which are using the .tar.gz would know how to update.

I could add another .tar.gz with the updates enabled like VSCodium-linux-x64-updates-enabled-1.80.1.23194.tar.gz.
Only the product.json need to be changed (adding "updateUrl": "https://vscodium.now.sh", "downloadUrl": "https://github.com/VSCodium/vscodium/releases")

What do you think?

[GitMensch]

I think that's not needed as the custom product.json, which overrides only the entries that are stored there, enables that for power-users (but that should be better documented).
See https://github.com/VSCodium/vscodium/blob/master/DOCS.md#how-to-use-a-different-extension-gallery (you see, bad doc...) for the place where to put the file, it should only (or additional, if you already have it) contain:

{
  "updateUrl": "https://vscodium.now.sh",
  "downloadUrl": "https://github.com/VSCodium/vscodium/releases",
}

and everything should be like before this change.

[mdickopp]

I think that's not needed as the custom product.json, which overrides only the entries that are stored there, enables that for power-users (but that should be better documented). […] and everything should be like before this change.

Thanks, this works perfectly for me!

[misog]

@daiyam

I use .appimage version. Before this "fix" I occasionally got Update alert in VSCodium that new version is available. I could click a button which opened this page https://github.com/VSCodium/vscodium/releases/ and I manually updated the .appimage file. Also I could do Help > Check for updates and then Help > Download available update which also opened https://github.com/VSCodium/vscodium/releases/

I was happy.

But now, after this "fix" I can not find Help > Check for updates and probably I will not get notified about new updates.

I am sad. Maybe if I did not investigate this I would be happy because I would live happily with outdated VSCodium version forever.

This "fix" is misleading because it does not "disable update on linux" but it does "disable update system on linux".

I would like to unfix this for appimages releases.

[GitMensch]

To "unfix locally", please see the possible local workaround above.

[misog]

Thanks. I know this can be "unfixed" by learning about product.json. Hopefully every Linux user who rely on build-in VSCodium update system will find this thread and unfix this and keep the VSCodium updated.

But why Linux users who rely on build-in system should unfix this by themselves? They knew that build-in update system could be conflicting with package manager (this is well known knowledge for Linux users and was not hot issue before) and they could just disable build-in update system or ignore alerts.

I propose to enable build-in system ASAP to save many man-hours of investigating "why update alerts are not working". And then create more granular improvements of VSCodium. It should be ASAP because following days many Linux users will get into this trap.

Also when more Linux users will install VSCodium for the first time without package manager, they would have no build-in update system out of the box just because of one config.

[geekley]

that should be better documented

when more Linux users will install VSCodium for the first time without package manager, they would have no build-in update system out of the box just because of one config

This can be solved for first-time users by including instructions in every release notes in GitHub, like: "if you download these versions on Linux, you will need to modify product.json to get auto-updates - instructions on the wiki".

I propose to enable build-in system ASAP

Even if this is done, I think it won't change installations which already auto-updated to the disabled auto-update version. So, these users will have to search for a solution anyways. :/
Unless it's possible to warn them in-editor using "announcements" or some other method on how to proceed.

I agree however, that AppImage version and any other version that you'd never (?) install with a package manager should probably have updates enabled out-of-the-box.

[misog]

I propose to enable build-in system ASAP

Even if this is done, it won't change installations which already auto-updated to the disabled auto-update version. So, these users will have to search for a solution anyways. :/
Unless it's possible to warn them in-editor using "announcements" or some other method on how to proceed.

The last release was 6 days ago, 4 workdays ago. It is summer so many users will update in following weeks. So one solution is to fix this ASAP and another solution is to do nothing and get more users in this update trap.

that should be better documented

when more Linux users will install VSCodium for the first time without package manager, they would have no build-in update system out of the box just because of one config

This can be solved for first-time users by including instructions in every release notes in GitHub, like: "if you download these versions on Linux, you will need to modify product.json to get auto-updates - instructions on the wiki".

This solution means that all existing Linux users who update by build-in system will get to the trap and some (most?) new Linux users will also will have no updates because how many of them want to learn about VSCodium specifics? Do they want to install coding tools and code, or play with VSCodium autoupdates?

I agree however, that AppImage version and any other version that you'd never (?) install with a package manager should probably have updates enabled out-of-the-box.

The issue is not "auto updates". But the issue is that whole build-in update mechanism was disabled; update alerts, updates in menu. Linux users who install appimage or build and maintain VSCodium by themselves and also Linux users who use package managers know that two update mechanism should not be combined and probably do not do that. But they maybe want to be reminded by build-in update alert and then update system with apt install or another package manager. Or they could disable update alerts because they know that package manager handles this.

[geekley]

some (most?) new Linux users will also will have no updates because how many of them want to learn about VSCodium specifics?

My assumption (correct me if I'm wrong) is that any new user who won't get auto-updates will download the files through GH Releases page, and so be exposed to very visible instructions (maybe shouldn't be a link to wiki).

they maybe want to be reminded by build-in update alert and then update system with apt install or another package manager

This seems like a power user who'd be easily able to find the instructions for re-enabling this.
Then again, having a "Check update" command that does nothing is weird. Unless it can be patched to show a warning in this case with the instructions to enable it.

This doesn't affect me, so I dunno. Maybe it really would be better to revert this for now and go with suggestion above:

better, be left as is and submitted as a patch to the distros

[misog]

Yes, but when I am exposed to GH release instructions then I need to actually read it and then also learn about product.json to enable build-in update system. Is it just me or people want to just install it and use it and possibly configure updates in GUI application? The default setting on Windows and Mac OS is that build-in update system is enabled. On Linux, now build-in system is disabled and can not enabled in GUI.

This seems like a power user who'd be easily able to find the instructions for re-enabling this.

Yes, it would better to disable build-in update alerts by default for installations by package managers. But not for the price of disabling it for all Linux users globally which really does not solve any real issue for package manager users. Because they know that build-in update is useless and also they can disable alerts. Yet it creates many problems for non-package manager users (no-update trap).

[DanielProg39]

I think there's no point in installing a deb, rpm or flatpak package without the repo, and packages released in GitHub releases are just meant to be easily available.

But regarding AppImages, this is a valid issue. I think we should find a way to automatically update them so that people don't have to update them themselves.

For packages hosted on GitHub, the solution could be either to make them install the appropriate repos with them, or to display a notification about an update which, when clicked, will automatically download and install the package from GitHub releases (I prefer the first option, of course). But this can be problematic for patching GitHub packages like this and keeping repo versions as they are, as differences between seemingly identical packages can be confusing.

As for bringing back the update check, because it will make it easier for people to track updates and install them using the package manager, I don't agree. It's more of a nuisance than a help, as the message leads to the GitHub page, and an inattentive user might accidentally download and install the package from there, and only then remember that they have the repo. I had a similar situation once. Every distribution has automatic updates enabled by default, which makes these update notifications even less useful.

In general, I don't think it's necessary to invent (or restore) an update mechanism for the packages in GitHub releases, since every Linux user will prefer to use the repo, but we really need to do something about AppImages, and since there is no repo for them, we can bring back the old update mechanism for them exclusively for the first time, until the new update system for AppImages would not be implemented.

[misog]

@DanielProg39

I think there's no point in installing a deb, rpm or flatpak package without the repo, and packages released in GitHub releases are just meant to be easily available.

That is valid point, but there are people who prefer deb, rpm or flatpak without repo. Also there can be scripts and scrapers who just scrape releases section and distribute files in internal private repository systems (no open repositories).

But regarding AppImages, this is a valid issue. I think we should find a way to automatically update them so that people don't have to update them themselves.

This exists, for example project zap https://github.com/srevinsaju/zap
But this issue is about the fact that build-in update alerts, menu options are enabled on Windows and MACOS by default, but on Linux, it is disabled by default.

As for bringing back the update check, because it will make it easier for people to track updates and install them using the package manager, I don't agree. It's more of a nuisance than a help, as the message leads to the GitHub page, and an inattentive user might accidentally download and install the package from there, and only then remember that they have the repo. I had a similar situation once. Every distribution has automatic updates enabled by default, which makes these update notifications even less useful.

That is not concern of VSCodium. Who wants to use some custom linux update mechanism, could use linux update mechanism like zap. The concern is that Windows users and MACOS users have enable build-in update mechanism in VSCodium and Linux users do not. VSCodium should not assume if and what custom update mechanism (such as zap) is used by the user. On Windows, for example, there are custom paid update programs which auto-update various applications as well. Should VSCodium also disable build-in update system for Windows with alerts and menu items as well? Also users who use deb files with no repository and no package manager just want to have option to check for updates from the menu or to have update alerts and then do the MANUAL update of deb file.

In general, I don't think it's necessary to invent (or restore) an update mechanism for the packages in GitHub releases, since every Linux user will prefer to use the repo, but we really need to do something about AppImages, and since there is no repo for them, we can bring back the old update mechanism for them exclusively for the first time, until the new update system for AppImages would not be implemented.

No, every Linux user does not prefer public repos and package managers. What exactly disabling build-in update mechanism (alerts and menu items) solves for users using package manager with repository? Just the alerts? Was there any other issue for them?

I suggest to revert this ASAP and do not trap users who do not use package managers into non-updatable state (no alerts and no menu items). Then solve it in such a way that detection of install method is applied (package manager vs no package manager) and leave update mechanism enabled (alerts and menu items) for all except package managers.

[misog]

A) There are four things which are concern of VSCodium:

• Menu button "Check for updates"
• Auto alert if new update is available
• Automatically updating the VSCodium by VSCodium
• Semi-manual process of updating VSCodium (open releases section in browser)

B) And two concerns of user

• Automatically updating VSCodium by custom program (dnf, apt, zap, MACOS paid updater, Windows paid updater, ...)
• Manual process of updating VSCodium

The "fix" disabled A) (except Automatically updating the VSCodium by VSCodium which was not available) for every Linux user, hoping that users use some other update program (dnf, apt, zap) or hoping that user will remember to manually update VSCodium.

[DanielProg39]

No, every Linux user does not prefer public repos and package managers.

When I say "everyone", I don't mean everyone, just most people. I'm aware of this, and I think that since there are only a few people who do this, and most of them are just very technical and privacy-conscious people who check the build's compliance with the source code, it might not be a problem for them to change a configuration slightly. So if we do decide whether to add update checks again for all packages, I'd prefer to keep the situation as it is (except for AppImages), but if we can only add them back for non-repo packages and leave repo packages without update checks, then of course we should do that and everyone will be happy.

scripts and scrapers who just scrape releases section and distribute files in internal private repository systems

Builds in any repository don't need update functionality, because that's what repositories do.

This exists, for example project zap

I know there are several similar projects, and even a way to make a package update itself. But I'm not a regular user of AppImages, so I'm just assuming that people who are better oriented in this area should come up with the best solution.

The concern is that Windows users and MACOS users have enable build-in update mechanism in VSCodium and Linux users do not.

That's because of the way packages are distributed on different systems. In Windows or MacOS, it's normal to install a program from somewhere on the Internet, and then it will notify you when a new update is available, and update itself (this is a primary way to install programs in Windows (since the App Store and Winget appeared not long ago), and is widely used in MacOS, since much software is not available in the Mac App Store). In Linux, on the other hand, the use of package managers and repositories is a primary option for installing and updating programs, so that the system's package manager (or any other, just to emphasise that there is already a package manager in the system, which is usually used) checks the repo, looks for updates, notifies about them and installs them if the user wants. And because of this, there is no need for the program to check for updates, because that is the package manager's job.

What exactly disabling build-in update mechanism (alerts and menu items) solves for users using package manager with repository? Just the alerts? Was there any other issue for them?

There are no major problems with this. It's just that Linux applications don't usually check for updates and notify you of them, so this is a bit weird and might confuse someone.

So now my point is: packages that are distributed via public repositories should not have update functionality, those that are not should have it, but if packages of both groups are meant to be identical I would prefer them not to have it, since package management in Linux is primarily done by the package manager and not by the application itself.
AppImage seems to be a different story, but at least bringing back update functionality for this type of package is a must.

[daiyam]

What exactly disabling build-in update mechanism (alerts and menu items) solves for users using package manager with repository?

Some users were getting confused, we did get issues about that.

It is true that most use package manager.

As you said, most users use package manager.

The update mechanism for Linux is bad compared to macOS or Windows.
On Linux, it just download the .tar.gz even if you are using an .appimage. It should download the .appimage and replace the previous version.
Since it is useless for most users and in a way, it's kinda broken for other users, it will stay disabled until a PR fix the mechanism.

The PR would need to do at least:

• detect if VSCodium was installed with a package manager
• if it isn't, enable the update check.

Maybe I'm old school but I've never expected a .deb, .rpm or .tar.gz package to update by itself. Automatic updates are always been managed by a package manager.

But I should have put out a public announcement about this change. If you have spent times about that, I'm sorry.

[paulcarroty]

• detect if VSCodium was installed with a package manager
• if it isn't, enable the update check.

I guess it will be easier to use build system and add no-update patch to deb/rpm/snap/flatpak/archpkg/whatever.

[daiyam]

I guess it will be easier to use build system and add no-update patch to deb/rpm/snap/flatpak/archpkg/whatever.

Not really, since we will need to go to each package manager which use the .tar.gz or the git to make sure they are turning off the update mechanism.
The .appimage is also based on the .deb (so disabled) where @misog would like to have it enabled.

I'm starting to think that the update mechanism should have never been enabled for Linux.
To have the updates managed by a package manager, is one of the big advantage of Linux over the macOS or Windows.

But we could provide a script that update the product.json to enabled the alerts.

[misog]

@daiyam

What exactly disabling build-in update mechanism (alerts and menu items) solves for users using package manager with repository?

Some users were getting confused, we did get issues about that.

It is true that most use package manager.

As you said, most users use package manager.

Yes, some of the most users were getting confused (user set A). Were those some users getting confused for months or years? I would have recommend them to learn Linux basics about package managers or a note in VSCodium documentation about updates and update alerts.

Certainly I would not disable update notifications (alerts) for all of the remaining users if they expect it (user set B). So this "fix" is a functional bug by definition for them.

A functional bug means that the program does not work as intended. For example, a user clicks the Save button, but the data is not saved.
Source: https://www.techtarget.com/searchsoftwarequality/definition/bug

1. Are you sure that the number of confused and would-be-confused-in-future users in set A is more than the number of all remaining users in set B?
2. Is it worth it to lower confusion for user in set A for the price of risking outdated software and possible unfixed vulnerabilities for users in set B?
3. How long it would take to prepare the PR to directly fix the confusion problem compared to the time of previous confusion period?
4. Are you sure that VSCodium is a type of software project where UI/UX is preferred over functionality and security?

And this is not problem of missing notes. If it is a feature which disables such important functionality, it should be minor, not patch version change (or equivalent).

[misog]

@DanielProg39 Linux is different from Windows and MACOS in a way that one should not assume anything about conventions and usualities. Because your standard machine or a popular distro is NOT whole Linux world.

The existing implemented capability of VSCodium software is to alert when new update is available and provide menu item for manual check. That's it. Now it is disabled for Linux because of some "confused" Linux users.

[daiyam]

By default, the update mechanism will stay disable on Linux.

But, I think there are 3 ways to resolve the update issue for unmanaged package:

1. provide a script to re-enable the update alerts
2. provide a script that checks for update, downloads the updated app and installs it (based on the type of package, defined in a config file)
3. provide separate packages with the update mechanism fully enabled but patched to do the download and install (different for each package)

I would go for 2. It would a good way to test if we want to do 3.

[paulcarroty]

More packages isn't best option to solve this tho.