"Download Now" button should respect the used installation method on Linux

Issue Type

Bug

Description

Edit: Originally this issue was specifically about the .deb installation method, but since this problem is not specific to it, I edited the issue to be more general.

How to reproduce

1. Install (an outdated version of) VS Code using one of the installation methods.
2. Open VSCode and wait for the (1) to appear on the settings icon.
3. Click on the settings icon and then on Download Now.

Expected behavior

VSCode starts the download of the latest version’s file (when the .tar.gz was used to install VS Code) or instructs the user to run an update through the relevant package manager.

Actual behavior

VS Code always starts the download of the latest version’s .tar.gz file.

Possible solution

VS Code could check what type of download was used to install and behave differently based on that. Checking whether a .deb was used could look something like this:

import { spawn } from 'child_process';

export function isDebInstallation(): Promise<boolean> {
  return new Promise(resolve => {
    spawn('dpkg', ['--list', 'code']).on('close', code => {
      resolve(code === 0);
    });
  });
}

Another option would be to include the information about what installation method was used in the release.

VS Code Info

VS Code version: Code 1.20.0 (c63189deaa8e620f650cc28792b8f5f3363f2c5b, 2018-02-07T17:10:15.949Z) OS version: Linux x64 4.13.0-32-generic

System Info

Item	Value
CPUs	Intel® Core™ i5-4590 CPU @ 3.30GHz (4 x 3300)
Load (avg)	1, 1, 1
Memory (System)	15.61GB (10.31GB free)
Process Argv	/usr/share/code/code .
Screen Reader	no
VM	0%

Reproduces without extensions

[Tyriar]

The think the ideal behavior for deb and rpm would actually be to either not show the download now button at all, or query the detected apt/yum/dnf for whether there is an update and then provide a notification (which defers to software updater?)

[monkeyhybrid]

@kanishk98 I just tested with a Ubuntu 16.04 virtual machine and you’re right, no default support for PackageKit. It’s an LTS release too, so could be around for a few years to come. Hmmm, that’s a shame. 😦

So I guess that leaves the options as:-

• Use apt, dpkg, dnf, yum, etc, to test if code package was installed.
• Require PackageKit as a package dependency (seems a bit overkill - maybe has other consequences?)
• Make tailored builds for package releases that disable update checks.
• Add an option to settings.json to allow users to disable update checks (which could be handy for other corner cases).