Changes in preparation for version 0.9.0

[jniesen]

The changelog entry for version 0.9.0 mentions a few backwards incompatibilities.

These commits address two of those:

• The official Hashicorp releases url provides binaries all the way back to version 0.1.0.
• All the binaries provided have the same "packer_" prefix
• Version 0.9.0 will only provide a single binary.

[bryantrobbins]

FYI, it looks like the current default URL used by the module is already no longer active:
https://dl.bintray.com/mitchellh/packer

Not sure when that happened, or if it means 0.9 is eminent, but I found myself requiring these changes in order to continue using the module, as only the base_url param is exposed in the currently released version.

[jniesen]

Thanks for looking. I just thought to check on this when I was about to use the module in another project.

[jniesen]

Sorry for the closing and re-opening. I realized this is still broken in 0.9.17.

[jonemo]

Thanks for putting this together @jniesen, and sorry for only looking at this now.

I see two potential problems with how the presence/absence of binaries is handled in this:

The first one is related to this sentence in the changelog:

If you install packer 0.9.0 over a previous packer installation, you must delete all of the packer-* plugin files or packer will load out-of-date plugins from disk.

If a user of this module applies a diff like the following to their manifest, the changelog comment suggests they will end up using the wrong plugins:

class { '::packer':
-  version => '0.8.5',
+  version => '0.10.0',
}

I think we'll need to add a block that ensures all packer-* files are absent when a version >= 0.9.0 gets installed.

The second one might be too obscure to matter, but the following scenario would lead to an incomplete uninstall:

1. User uses this package without stating a version number explicitly (include ::packer), and therefore has 0.8.5 installed.
2. We update the default version number installed by this package to >=0.9.0 in the future
3. User wants to remove packer from their managed server: class {'::packer': ensure => absent}
4. Only the main packer binary will be removed, packer-* will stay behind

A possible solution might be to always ensure both packer and packer-* are removed.

Let me know if you want to tackle these two on your branch, or if you want me to take a look.

[joshuaspence]

You could always bump the module version and state that the new version is not compatible with pre-0.9 versions of Packer.

[jdavisp3]

I think most of these have been incorporated into the mainline already.