After looking around a little bit, I actually can’t see any evidence that any of the _package resources can take an http “source” with the exception of “gem_package”. The standard way to go about this if you can’t use the OS’s built-in package manager is to retrieve the file with remote_file and then install it. You’re pretty-much just running up against “Linux, BSD, and Mac (sort of) have a package management system, Windows doesn’t”.
That being said, it does seem like a reasonable feature to have and it probably wouldn’t be too hard for you to implement if it’s very important to you. I’m sure others would appreciate the contribution.
Matt Moretti
I disagree.
winodow_package "could" have been written such that when the source is a URL (http://), it would do a remote_file first, and then execute the local package, all underneath the covers. Then its behavior is in-line with the package resource.
Chris
-----Original Message-----
From: Daniel DeLeo [mailto: "> ] On Behalf Of Daniel DeLeo
Sent: Wednesday, February 11, 2015 12:08 PM
To: ">
Subject: [chef] Re: RE: Re: Why is my windows_package source attribute getting mucked up?
On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:
> More (annoying) inconsistencies (in expectations) between Windows and Linux based nodes.
>
> Chris
I agree there are a lot of areas where Windows functionality needs to catch up, but this isn’t one of them. On Linux when you install a package that doesn’t come from a centralized package repo, you have to use a separate remote file to fetch it as well. The difference is that most Linux distros come with a centralized package repo, which provides most of the packages you want. The only way Chef could make windows behave similarly is to force you to install Chocolatey when you install Chef. FWIW I had the exact same experience on Solaris a few years back where the only centralized package repos are (were?) 3rd party so you had to do a bit of extra work to fetch everything.
--
Daniel DeLeo
Archive powered by MHonArc 2.6.16.