Allow users to opt-out of apt repository install #22145
Comments
|
Actually; I just realized that the reason of the failure is because I simply removed the folder 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. |
|
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. |
|
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 This can be done easily by checking the return code of 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. 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 Edition: fixed the command to use a functional one |
|
@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 It will annoy some users but there would be ways to disable it (eg. env var or modified |
|
@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 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:
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 :) |
|
@jandsu thanks for your understanding, I think doing both checks before writing the vscode.list will be best:
Not sure I'll be able to get to this in March but open to PRs in the meantime. |
|
Closing for housekeeping purposes the lack of interest. Still open to PRs if you care though. |
|
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! |
|
@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:
Regarding the environment-variable approach: this variable should be set in the Would you consider other approaches, such as:
^^^^ what I am trying to say is that there might be a mechanism that signals vscode that user has custom |
|
@DimanNe yes those 2 would be good if they were contributed, another approach is to have a hard coded string like Yes, the environment variable would need to be set for whatever user runs apt. |
Currently, vscode.list is added to /etc/apt/sources.d/ whenever it doesn't exist. With this patch, the new behaviour is as follows: 1. If the user already has the Microsoft source file installed for apt, sources won't be added 2. If the user sets debconf-set-selections to set code/add-microsoft-repo to false, the sources won't be added 3. If sources might be added, the script checks whether it makes sense to (over)write them (i.e. the file doesn't exist, is old or has been disabled during some OS upgrade) 4. If is makes sense and the code/add-microsoft-repo is not set, the user is asked to cofirm, whether they actually want Microsoft sources to be installed (setting code/add-microsoft-repo to the selected value) 5. Only if it makes sense and the user agrees, the sources are installed This change will mostly affect new users or those reinstalling vscode. Personally, I feel like the whole approach of automatically adding the repo is very invasive, and would prefer that it not be done at all. However, with this change, it is up to the user whether they want it to be installed or not. Since the default is set to true, users that install vscode in noninteractive environments get the current behavior. Existing users will either be asked once or never (depending on whther step 4 above gets triggered). New users will be asked unless they make a decision ahead of time using debconf-set-selections. With this, microsoft#22145 and duplicates should be sufficiently addressed. Signed-off-by: Matthias Breithaupt <m.breithaupt@vogl-electronic.com>
Currently, vscode.list is added to /etc/apt/sources.d/ whenever it doesn't exist. With this patch, the new behaviour is as follows: 1. If the user already has the Microsoft source file installed for apt, sources won't be added 2. If the user sets debconf-set-selections to set code/add-microsoft-repo to false, the sources won't be added 3. If sources might be added, the script checks whether it makes sense to (over)write them (i.e. the file doesn't exist, is old or has been disabled during some OS upgrade) 4. If is makes sense and the code/add-microsoft-repo is not set, the user is asked to cofirm, whether they actually want Microsoft sources to be installed (setting code/add-microsoft-repo to the selected value) 5. Only if it makes sense and the user agrees, the sources are installed This change will mostly affect new users or those reinstalling vscode. Personally, I feel like the whole approach of automatically adding the repo is very invasive, and would prefer that it not be done at all. However, with this change, it is up to the user whether they want it to be installed or not. Since the default is set to true, users that install vscode in noninteractive environments get the current behavior. Existing users will either be asked once or never (depending on whther step 4 above gets triggered). New users will be asked unless they make a decision ahead of time using debconf-set-selections. With this, microsoft#22145 and duplicates should be sufficiently addressed. Signed-off-by: Matthias Breithaupt <m.breithaupt@vogl-electronic.com>
Currently, vscode.list is added to /etc/apt/sources.d/ whenever it doesn't exist. With this patch, the new behaviour is as follows: 1. If the user already has the Microsoft source file installed for apt, sources won't be added 2. If the user sets debconf-set-selections to set code/add-microsoft-repo to false, the sources won't be added 3. If sources might be added, the script checks whether it makes sense to (over)write them (i.e. the file doesn't exist, is old or has been disabled during some OS upgrade) 4. If is makes sense and the code/add-microsoft-repo is not set, the user is asked to cofirm, whether they actually want Microsoft sources to be installed (setting code/add-microsoft-repo to the selected value) 5. Only if it makes sense and the user agrees, the sources are installed This change will mostly affect new users or those reinstalling vscode. Personally, I feel like the whole approach of automatically adding the repo is very invasive, and would prefer that it not be done at all. However, with this change, it is up to the user whether they want it to be installed or not. Since the default is set to true, users that install vscode in noninteractive environments get the current behavior. Existing users will either be asked once or never (depending on whther step 4 above gets triggered). New users will be asked unless they make a decision ahead of time using debconf-set-selections. With this, microsoft#22145 and duplicates should be sufficiently addressed. Signed-off-by: Matthias Breithaupt <m.breithaupt@vogl-electronic.com>
|
Reopening because of #221285 (comment) |
|
The issue has mostly been fixed with the addition of an interactive post-install script that prompts the user to confirm whether they would like to add the Microsoft repository. I plan to merge in #227837 next month to finally resolve this issue. |
|
@andreineculau the manual workaround you mentioned at #221285 (comment) should not be needed anymore with the latest VS Code Insiders. As part of the endgame process, could you confirm that the issue is fixed sometime this week? |
|
Verification steps for maintainers: ensure that the Linux TPI #226675 is still valid. |
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:
Steps to Reproduce:
sudo apt-get install code==> 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 codeto 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
The text was updated successfully, but these errors were encountered: