-
Notifications
You must be signed in to change notification settings - Fork 2.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
non msi packages must explicitly provide a source attribute on install #4277
Conversation
👍 |
I think this should look at new_resource.package_name so that the name can be something less crazy, e.g.
It'd actually be way more intuitive if this was registry_name or registry_key or something. hrm. |
@@ -83,11 +83,13 @@ to better align with other ssh related options. | |||
|
|||
`windows_package` now supports more than just `MSI`. Most common windows installer types are supported including Inno Setup, Nullsoft, Wise and InstallShield. The new allowed `installer_type` values are: `inno`, `nsis`, `wise`, `installshield`, `custom`, and `msi`. | |||
|
|||
Non `:msi` package names should match the softwares `DisplayName` property expected to be found in the registry keys mentioned below. Further, they must explicitly include a package `source` attribute when using the `:install` action. It will not default to the package name if missing. Without the name matching the software display name, non `:msi` packages will always reconverge on `:install`. |
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.
DisplayName
is a registry key property, not a chef resource property. we should be more clear about that. It's not that we don't say that, but DisplayName
sticks out (besides being camel case) to me as something I might set on my resource.
For proper behavior, the
package_name
property for Windows packages other than MSIs must be set to match ...
On second thought, we should remove/combine this paragraph with the one below that says almost the same thing, lists the registry key locations, but also mentions that the add/remove name might be more accessible.
One thing I noticed just a bit ago is that the cookbook does require an explicit source and does not defaut a missing source to be the name. That was one of the slight differences in the resource that did not copy over. So this PR should better mimic what we had in the cookbook. |
I've adjusted to review comments. |
@@ -34,6 +34,13 @@ class Windows < Chef::Provider::Package | |||
|
|||
require 'chef/provider/package/windows/registry_uninstall_entry.rb' | |||
|
|||
def define_resource_requirements | |||
requirements.assert(:install) do |a| | |||
a.assertion { @new_resource.source unless package_provider == :msi } |
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.
Use the new_resource
accessor rather than the instance variable.
👍 check the use of instance variables vs accessors, otherwise 🏆 |
argh well thats embarassing. should have caught those. consider them smitten |
👍 |
def define_resource_requirements | ||
requirements.assert(:install) do |a| | ||
a.assertion { new_resource.source unless package_provider == :msi } | ||
a.failure_message Chef::Exceptions::NoWindowsPackageSource, "Source for package #{new_resource.name} must be specified in the resource's source property for package to be installed because the package_name property is used to test for package installation state for this package type." |
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.
This message could probably be shortened :)
Also, I think the sentence is missing a 'the' in "source property for package"
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.
Yeah, it's a little tough. MSI doesn't require source, so I think this is an attempt at proactive documentation.
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.
Not seeing the missing "the" but to @btm's point, this is tough to get just right and make it concise. We could just say that the source is required and leave it at that but if the user uses a url/path as the package_name, then they might be confused why they need to specify a source
which they don't have to do for MSIs.
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.
I guess you could add a "the" here:
"Source for package #{new_resource.name} must be specified in the resource's source property for package to be installed because the package_name property is used to test for the package installation state for this package type."
👍 again |
5b2afe3
to
f99c222
Compare
Also Matt, you may need to wait to update the DOC changes for the required source, as those will be for 12.7 |
do we do doc changes for patch releases? |
Per James, we should update the doc_changes if the change is significant enough. |
f99c222
to
41bd0ba
Compare
There was some merge conflict fallout here I had to address with the |
non msi packages must explicitly provide a source attribute on install
Currently one can use a package
source
location as a package name:In the case of non-
:msi
installer_type
s, this will result in package resources reconverging an:install
action even though the package has been previously installed.The reason is that when the
windows_package
scans the registry for all current software installations, it cannot search by install path or url. So it searches by theDisplayName
property in the registry keys mentioned above. If you use a source path as the name of a non:msi
windows_package
it will not find any currently installed package and will therefore attempt to reinstall the package.:msi
packages get around this because there is a well known API for extracting the id of the installed MSI package from a.msi
file.Requiring an explicit
source
for non:msi
packages will reduce confusion here around idempotency.