[chef] Re: Re: Re: Re: Re: Providing specific version numbers of packages to install with yum...

[Brad Knowles < >]

On Oct 24, 2011, at 10:08 AM, Joshua Timberman wrote:

> There isn't a semantic to do version constraints on package resources
> 
> However, you could assign it through a node attribute. Then when you have 
> vetted a new version for your infrastructure you can modify the version. I 
> suggest setting a base version in the cookbook's attributes file as so:
> 
> default['erlang']['version'] = "R14B-03.3.el5"
> 
> Then you can modify through a role:
> 
> name "erlang-service"
> default_attributes(
>  'erlang' => {
>    'version' => "R14B-03.4.el5"
>  }
> )
> 
> Replace "erlang-service" with the appropriate name of the service that uses 
> Erlang, e.g., rabbitmq.

I'll give this a shot, but it seems that we still will have a timing issue 
here.  I've gone through this a couple of times, and I'm convinced that the 
issue I'm running into is that the EPEL Erlang repo is not being fully 
installed before yum goes to install the correct version of the Erlang 
package.  Most recently when I tried this (hard-coding a specific Erlang 
version as part of the recipe), I got this error:

FATAL: Chef::Exceptions::Package: yum_package[erlang] (erlang::default line 
35) had an error: Version R14B-03.3.el5 of erlang not found. Did you specify 
both version and release? (version-release, e.g. 1.84-10.fc6)

However, I know that if I run chef-client again on this node, everything will 
install fine.  I'm wondering what is the proper way to ensure that the EPEL 
Erlang repo is fully installed before trying to do the yum install of the 
package -- put the yum install in a ruby_block, to force it to be as late in 
the process as possible?  Is there a way to cause the install of the EPEL 
Erlang repo to happen a lot earlier in the process?

Thanks!

-- 
Brad Knowles 
<
 >
SAGE Level IV, Chef Level 0.0.1