-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
[Spec] Windows Package Manager Repair functionality Design spec #3943
[Spec] Windows Package Manager Repair functionality Design spec #3943
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Comments/Concerns: @ImJoakim |
doc/specs/#148 - Repair Support.md
Outdated
- the repair command will not work if the installer does not have a custom repair switch specified in the YAML manifest file. | ||
- the repair command will not work if the installed Burn/Exe installer type doesn't correlated to the remote installer type that has a custom repair switch specified in the YAML manifest file. | ||
|
||
## Future considerations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we handle elevation requirements when the modification requirement is different from the install requirement? What about when a package is installed in machine scope and a non-elevated session is attempting the modify?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should explore real-world scenarios where the requirements for modifying elevation differ from those for installation.
Currently, our design assumes that the requirements for modification elevation align with those for installation, similar to uninstallation.
The expectation/assumption for "when a non-elevated session attempts to modify a package installed for machine scope", the installer will prompt for elevation appears to be the case with some sample runs. However, when a package installed for user scope is run in an admin context, the repair operation is restricted due to possible security risks.
This comment has been minimized.
This comment has been minimized.
@Madhusudhan-MSFT whats the latest update on this? |
Since the feature has been released, we should make sure this spec is accurate and get it merged :) |
This commit introduces the initial design specification for the repair functionality in Windows Package Manager. This new feature will allow users to repair installed packages using the Windows Package Manager.
This commit fixes the spelling-bot report by adding the expected entries to the expect.txt file.
…epair and InstallerRepair in future scope
… �RepairBehavior� and change its scope to Installer object.
909dc59
to
c04357d
Compare
- Corrected typos - Included a section on Elevation Requirements - Highlighted potential issues with repairing MSI-based installers using msiexec when the original installer is missing or renamed.
This PR introduces the Design specification for the repair functionality in Windows Package Manager. This new feature will allow users to repair installed packages using the Windows Package Manager.
Related to:
Microsoft Reviewers: Open in CodeFlow