Skip to content
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

Merged
merged 3 commits into from
Dec 16, 2015

Conversation

mwrock
Copy link
Member

@mwrock mwrock commented Dec 11, 2015

Currently one can use a package source location as a package name:

package 'http://mercurial.selenic.com/release/windows/Mercurial-3.6.1-x64.exe' do
  checksum 'febd29578cb6736163d232708b834a2ddd119aa40abc536b2c313fc5e1b5831d'
end

In the case of non-:msi installer_types, 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 the DisplayName 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.

@chefsalim
Copy link
Contributor

👍

@mwrock mwrock changed the title add idempotency note regarding non msi installs to doc changes non msi packages must explicitly provide a source attribute on install Dec 11, 2015
@btm
Copy link
Contributor

btm commented Dec 11, 2015

def uninstall_registry_entries
  @uninstall_registry_entries ||= Chef::Provider::Package::Windows::RegistryUninstallEntry.find_entries(new_resource.name)
end

I think this should look at new_resource.package_name so that the name can be something less crazy, e.g.

package "remove the burning foxes" do
  package_name "FireFox Internet Browser of Webs v11.2.0 sp12"
  action :uninstall
end

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`.
Copy link
Contributor

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.

@mwrock
Copy link
Member Author

mwrock commented Dec 11, 2015

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.

@mwrock
Copy link
Member Author

mwrock commented Dec 12, 2015

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 }
Copy link
Contributor

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.

@btm
Copy link
Contributor

btm commented Dec 12, 2015

👍 check the use of instance variables vs accessors, otherwise 🏆

@mwrock
Copy link
Member Author

mwrock commented Dec 12, 2015

argh well thats embarassing. should have caught those. consider them smitten

@mwrock mwrock closed this Dec 12, 2015
@mwrock mwrock reopened this Dec 12, 2015
@btm
Copy link
Contributor

btm commented Dec 14, 2015

👍

@lamont-granquist lamont-granquist added this to the Accepted Minor milestone Dec 15, 2015
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."
Copy link
Contributor

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"

Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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."

@chefsalim
Copy link
Contributor

👍 again

@chefsalim
Copy link
Contributor

Also Matt, you may need to wait to update the DOC changes for the required source, as those will be for 12.7

@mwrock
Copy link
Member Author

mwrock commented Dec 15, 2015

do we do doc changes for patch releases?

@chefsalim
Copy link
Contributor

Per James, we should update the doc_changes if the change is significant enough.
(Note: the process may change for 12.7)

@mwrock
Copy link
Member Author

mwrock commented Dec 16, 2015

There was some merge conflict fallout here I had to address with the properties changes. There is still one app veyor test failing but it is related to easy_install and completely unrelated to this PR. So merging.

mwrock added a commit that referenced this pull request Dec 16, 2015
non msi packages must explicitly provide a source attribute on install
@mwrock mwrock merged commit 7677d4b into master Dec 16, 2015
@mwrock mwrock deleted the mwrock/package branch December 16, 2015 00:24
@chef chef locked and limited conversation to collaborators Nov 16, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants