-
Notifications
You must be signed in to change notification settings - Fork 904
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot override remembered install arguments on upgrade #2761
Comments
A workaround should be to use the Another workaround for is to use |
This allows overriding of remembered package parameters and install arguments during upgrade. So a user can pass in different package parameters or arguments without having to completely reinstall the package or turn of remembered arguments. At this point in the remembered arguments, the CacheLocation and CommandExecutionTimeout are already set even if not passed in explicitly, so there is no way to check if they are being overridden by the user. And the switch also cannot be checked, because the lack of a switch normally would mean that they are just relying on the remembered args to remember it.
I've opened #3003, which allows for overriding of package parameters and install arguments. However, due to reasons described in the PR, it would not be possible to override switches. My thoughts are to add information about what items can be overridden as a part of chocolatey/docs#404, and information about how to "reset" the argument during upgrade by using |
This allows overriding of remembered package parameters and install arguments during upgrade. So a user can pass in different package parameters or arguments without having to completely reinstall the package or turn of remembered arguments. At this point in the remembered arguments, the CacheLocation and CommandExecutionTimeout are already set even if not passed in explicitly, so there is no way to check if they are being overridden by the user. And the switch also cannot be checked, because the lack of a switch normally would mean that they are just relying on the remembered args to remember it.
This allows overriding of remembered package parameters and install arguments during upgrade. So a user can pass in different package parameters or arguments without having to completely reinstall the package or turn of remembered arguments. At this point in the remembered arguments, the CacheLocation and CommandExecutionTimeout are already set even if not passed in explicitly, so there is no way to check if they are being overridden by the user. And the switch also cannot be checked, because the lack of a switch normally would mean that they are just relying on the remembered args to remember it.
This allows overriding of remembered package parameters and install arguments during upgrade. So a user can pass in different package parameters or arguments without having to completely reinstall the package or turn of remembered arguments. At this point in the remembered arguments, the CacheLocation and CommandExecutionTimeout are already set even if not passed in explicitly, so there is no way to check if they are being overridden by the user. And the switch also cannot be checked, because the lack of a switch normally would mean that they are just relying on the remembered args to remember it.
This allows overriding of remembered package parameters and install arguments during upgrade. So a user can pass in different package parameters or arguments without having to completely reinstall the package or turn of remembered arguments. At this point in the remembered arguments, the CacheLocation and CommandExecutionTimeout are already set even if not passed in explicitly, so there is no way to check if they are being overridden by the user. And the switch also cannot be checked, because the lack of a switch normally would mean that they are just relying on the remembered args to remember it.
This allows overriding of remembered package parameters and install arguments during upgrade. So a user can pass in different package parameters or arguments without having to completely reinstall the package or turn of remembered arguments. At this point in the remembered arguments, the CacheLocation and CommandExecutionTimeout are already set even if not passed in explicitly, so there is no way to check if they are being overridden by the user. And the switch also cannot be checked, because the lack of a switch normally would mean that they are just relying on the remembered args to remember it.
This allows overriding of remembered package parameters, install arguments, cache location and execution timeout during upgrade. So a user can pass in different package parameters or arguments without having to completely reinstall the package or turn off remembered arguments. Switch arguments cannot be checked, because the lack of a switch normally would mean that they are just relying on the remembered args to remember it, so there is no way to determine if an override of the remembered args is appropriate.
This allows overriding of remembered package parameters, install arguments, cache location and execution timeout during upgrade. So a user can pass in different package parameters or arguments without having to completely reinstall the package or turn off remembered arguments. Switch arguments cannot be checked, because the lack of a switch normally would mean that they are just relying on the remembered args to remember it, so there is no way to determine if an override of the remembered args is appropriate.
Based on the changes in the associated PR's for this issue, I am going to have to bump this issue from the 2.3.0 release, and instead look at this again in the 2.4.0. The suggested changes to the INuGetService mean that this would essentially be a breaking change, that would need a corresponding change in the Chocolatey Licensed Extension, which we haven't planned to do at the minute. Instead of holding up the release of 2.3.0, we will look to do the work in this issue in a later release. Apologies for any inconvenience that this causes. |
This allows overriding of remembered package parameters, install arguments, cache location and execution timeout during upgrade. So a user can pass in different package parameters or arguments without having to completely reinstall the package or turn off remembered arguments. Switch arguments cannot be checked, because the lack of a switch normally would mean that they are just relying on the remembered args to remember it, so there is no way to determine if an override of the remembered args is appropriate.
What You Are Seeing?
When upgrading a single package, I cannot add additional options. E.g. if thunderbird was installed with:
and I upgrade with:
I get:
So the /NoStop is dropped.
What is Expected?
The passed --params would override the remembered args.
System Details
[System.Environment]::OSVersion.version.tostring()
): 10.0.19044.0$PSVersionTable
):choco --version
): 1.1.0The text was updated successfully, but these errors were encountered: