Allow users to opt-out of apt repository install

[jandsu]

• VSCode Version: Code 1.10.1 (653f873, 2017-03-02T00:47:58.633Z)
• OS Version: Linux x64 4.4.0-64-generic
• Extensions: not relevant

---

My team and I use Artifactory to cache locally the .deb files rather than downloading from the Internet over and over again.

The consequence is that a dev's box has a single sources.list file holding all the entries reading from the site-local cache rather than from the Internet.

This eventually leads to following error when installing VS Code:

$ sudo apt-get install code
...
/var/lib/dpkg/info/code.postinst: line 66: /etc/apt//sources.list.d/vscode.list: No such file or directory
dpkg: error processing package code (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 code
E: Sub-process /usr/bin/dpkg returned an error code (1)

Steps to Reproduce:

1. Configure the GPG key and APT repository manually (inspired by https://code.visualstudio.com/docs/setup/linux#_installation but using other files / folders to suite needs of site-local cache)
2. run sudo apt-get install code
3. the script /var/lib/dpkg/info/code.postinst fails as shown above

==> this script seems to silently try to add the repo to the sources list of the user.

This is not the Ubuntu / Debian usual way

This may be a good idea for the .deb downloaded from the web site directly, but it should not be run when the user has already configured his system to grab VS Code from a repo (Microsoft's or another) somewhere.

How can you know if the repo is already configured?
You may run apt-cache madison code to check if VS Code can be found and where.

The key is that the user should not be forced to have the GPG key and the apt source configured as you expect, because some of them will simply have different requirements.

Thanks

[jandsu]

Actually; I just realized that the reason of the failure is because I simply removed the folder /etc/apt/sources.list.d and all my sources are in a single file, which I get easily on all developer's boxes using a simple curl command.

If the folder still, exists there is no failure, however, vscode still has added its own repo... which I want to avoid to use our local cache.

[Tyriar]

It would be good to have some check(s) to see if we should not set up the folder, such as checking if vscode.list exists, checking an environment variable etc.

[jandsu]

Hello @Tyriar,

As explained earlier in this report, the vscode.list does not necessarily exist, so checking this is not reliable. What you want to know is if the code package is to be found somewhere using the current configuration.

This can be done easily by checking the return code of dpkg -l code.

Check for instance the following command on a system with the vscode repo setup and on another with the vscode repo not setup and see the difference for yourself.

apt-cache show code &> /dev/null && echo found || echo not found

Nevertheless, be warned, adding a new repo source on a system is not very common and may upset some users, in particular advanced users (who are the target audience of vscode).

On my box for instance, unless I edit the offending script to insert an exit 0, I can no longer run system updates w/o an error.

Edition: fixed the command to use a functional one

[Tyriar]

@jandsu your examples aren't really what we want though. We want to make it as streamlined/easy as possible to get automatic updates working for users. Just checking for the presence of the code package would not install the repo when upgrading from older versions to newer versions for example. The way Chrome does it which is probably what we will want to do is check vscode.list and update it only if it does not exist or has been disabled after upgrading the OS (ie. don't touch if it's been commented out manually),

It will annoy some users but there would be ways to disable it (eg. env var or modified vscode.list), the benefits of enhanced security, staying up to date and not annoying the user with the download now popup far outweigh a little annoyance to powerusers that has workarounds. An apt developer actually recommended Chrome's approach in #2973 (comment)

[jandsu]

@Tyriar, you are right: in my attempt to be able to check the status code of the command (and be able to reliably call it from a script), I overlooked the fact that those commands would issue "found" when the package is only installed manually as former vscode versions. Sorry about that.

So please disregard these examples... my original issue description was referencing apt-cache madison and this one works well to check whether the package is grabbed from a repo or not.

Unfortunately it has no status code returned and you'd have to parse the output... not very satisfying...

Anyway, I clearly understand the goal which is very nice! And thanks for the link... BTW, you will notice that two comments below (in #2973 (comment)) the recommended way is to have 2 separated packages:

• one for configuration
• one for the actual program

In that case, the user is free to install one or the other... This is obviously a bit less convenient for non-power users...

I don't want to seem to push hard in one or the other direction: I will not pretend that I am a specialist in .deb repos, it is just that vscode is the single package that breaks our local cache configuration right now... whatever way you pick up to circumvent the issue will be fine by me :)

[Tyriar]

@jandsu thanks for your understanding, I think doing both checks before writing the vscode.list will be best:

1. If a $VSCODE_SKIP_REPO (or similar) is set, skip the repo/key install
2. If vscode.list has been modified and its contents is not recognizable (eg. it's commented out), skip the repo/key install

Not sure I'll be able to get to this in March but open to PRs in the meantime.

[Tyriar]

Closing for housekeeping purposes the lack of interest. Still open to PRs if you care though.

[vscodebot]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[DimanNe]

@Tyriar Thank you for pointing out that my issue was a duplicate of this.

Just to double-check, am I right that you are not opposed to these:

• If a $VSCODE_SKIP_REPO (or similar) is set, skip the repo/key install
• If vscode.list has been modified and its contents is not recognizable (eg. it's commented out), skip the repo/key install

Regarding the environment-variable approach: this variable should be set in the apt (or root) user, right?

Would you consider other approaches, such as:

• if there is vscode.sources (or any .sources file with predefined name) do not install vscode.list
• if there is I-will-be-maintaining-my-own-vscode-file-do-not-add-your-own.list (or any other .list file with predefined name) do not install vscode.list

^^^^ what I am trying to say is that there might be a mechanism that signals vscode that user has custom *.sources / *.list and that vscode should not try installing its own.

[Tyriar]

@DimanNe yes those 2 would be good if they were contributed, another approach is to have a hard coded string like # vscode-skip-repo in the .list. Whatever happens we could document it at https://code.visualstudio.com/docs/setup/linux.

Yes, the environment variable would need to be set for whatever user runs apt.

[m-byte]

@Tyriar I just opened a PR for this (#221285). I felt like the most Debian way of approaching this would be using debconf, not environment variables.

For automatic installations, users can use debconf-set-selections to set code/add-microsoft-repo to either true or false before installing vscode (Default for non-interactive setups is true).
If they already have to current Microsoft repo enabled (checked using apt-cache policy), it won't be added. This helps with upgrades to Ubuntu 24.04, since all .list files are converted to the .sources format and then added again by vscode, causing apt to complain about duplicate sources.
If the postinst is not sure about whether the user wants the sources or not, the user gets the option to confirm whether they want the sources to be installed.

[rzhao271]

\closedWith cd340e6

[Tyriar]

Reopening because of #221285 (comment)