# Chef-client gem install --pre doesn't find second level dependencies?

**URL:** <https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779>\
**Category:** Chef Infra (archive)\
**Created:** [April 19, 2011, 11:41pm UTC](https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779 "2011-04-19T23:41:50Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![KC\_Braunschweig](https://avatars.discourse-cdn.com/v4/letter/k/ea5d25/32.png) [@KC\_Braunschweig](https://discourse.chef.io/u/KC_Braunschweig)\
**Post date:** [April 19, 2011, 11:41pm UTC](https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779/1 "2011-04-19T23:41:50Z")

</div>

Am I missing something here? I’ve tried a few times now doing a clean  
install of chef only for client install purposes on both RHEL and  
ubuntu (10.04) using rubygems. It seems that it when installing a  
prerelease version, you can’t find second level dependencies or  
something like that?

Specifically you get things like:

kc@t5400:~$ sudo gem install chef --pre -y  
INFO: `gem install -y` is now default and will be removed  
INFO: use --ignore-dependencies to install only the gems you list  
ERROR: Error installing chef:  
mixlib-authentication requires mixlib-log (\>= 0, runtime)

Clearly it resolved that chef needs mixlib-authentication but then it  
couldn’t find mixlib-log ?? But that is there and you can install it  
explicitly, but only if you don’t pass --pre

k@t5400:~$ sudo gem install mixlib-log --pre  
ERROR: could not find gem mixlib-log locally or in a repository

k@t5400:~$ sudo gem install mixlib-log  
Successfully installed mixlib-log-1.3.0  
1 gem installed  
Installing ri documentation for mixlib-log-1.3.0…  
Installing RDoc documentation for mixlib-log-1.3.0…

Maybe most folks upgraded from chef 0.9x so they didn’t notice, but  
this is irritating. Seems like I have to manually specify all the  
dependencies that don’t have a prerelease version first and then I can  
install chef --pre? I know this will go away once all the chef bits  
aren’t in prerelease anymore, but if this is a gem weirdness, it’ll  
just keep happening. On the other hand, I might just be missing  
something that would make this a non-issue.

KC

---

<div class="post-metadata">

**Author:** ![Adam\_Jacob](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/adam_jacob/32/292_2.png) [@Adam\_Jacob](https://discourse.chef.io/u/Adam_Jacob)\
**Post date:** [April 20, 2011, 12:09am UTC](https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779/2 "2011-04-20T00:09:20Z")

</div>

What version of ruby are you using, KC? I think this is actually  
caused by Rubygems no longer supporting particular versions of ruby.

Adam

On Tue, Apr 19, 2011 at 4:41 PM, KC Braunschweig  
[kcbraunschweig@gmail.com](mailto:kcbraunschweig@gmail.com) wrote:

> Am I missing something here? I've tried a few times now doing a clean  
> install of chef only for client install purposes on both RHEL and  
> ubuntu (10.04) using rubygems. It seems that it when installing a  
> prerelease version, you can't find second level dependencies or  
> something like that?
> 
> Specifically you get things like:
> 
> kc@t5400:~$ sudo gem install chef --pre -y  
> INFO: `gem install -y` is now default and will be removed  
> INFO: use --ignore-dependencies to install only the gems you list  
> ERROR: Error installing chef:  
> mixlib-authentication requires mixlib-log (\>= 0, runtime)
> 
> Clearly it resolved that chef needs mixlib-authentication but then it  
> couldn't find mixlib-log ?? But that is there and you can install it  
> explicitly, but only if you don't pass --pre
> 
> k@t5400:~$ sudo gem install mixlib-log --pre  
> ERROR: could not find gem mixlib-log locally or in a repository
> 
> k@t5400:~$ sudo gem install mixlib-log  
> Successfully installed mixlib-log-1.3.0  
> 1 gem installed  
> Installing ri documentation for mixlib-log-1.3.0...  
> Installing RDoc documentation for mixlib-log-1.3.0...
> 
> Maybe most folks upgraded from chef 0.9x so they didn't notice, but  
> this is irritating. Seems like I have to manually specify all the  
> dependencies that don't have a prerelease version first and then I can  
> install chef --pre? I know this will go away once all the chef bits  
> aren't in prerelease anymore, but if this is a gem weirdness, it'll  
> just keep happening. On the other hand, I might just be missing  
> something that would make this a non-issue.
> 
> KC

--  
Opscode, Inc.  
Adam Jacob, Chief Product Officer  
T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)

---

<div class="post-metadata">

**Author:** ![Mark\_J\_Reed](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/mark_j_reed/32/776_2.png) [@Mark\_J\_Reed](https://discourse.chef.io/u/Mark_J_Reed)\
**Post date:** [April 20, 2011, 12:17am UTC](https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779/3 "2011-04-20T00:17:57Z")

</div>

That might make sense on RHEL \<= 5, but Ubuntu 10.04 comes with a  
pretty recent ruby - your choice of 1.8.7 or 1.9.2, IIRC.

On Tuesday, April 19, 2011, Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:

> What version of ruby are you using, KC? I think this is actually  
> caused by Rubygems no longer supporting particular versions of ruby.
> 
> Adam
> 
> On Tue, Apr 19, 2011 at 4:41 PM, KC Braunschweig  
> [kcbraunschweig@gmail.com](mailto:kcbraunschweig@gmail.com) wrote:
> 
> > Am I missing something here? I've tried a few times now doing a clean  
> > install of chef only for client install purposes on both RHEL and  
> > ubuntu (10.04) using rubygems. It seems that it when installing a  
> > prerelease version, you can't find second level dependencies or  
> > something like that?
> > 
> > Specifically you get things like:
> > 
> > kc@t5400:~$ sudo gem install chef --pre -y  
> > INFO: `gem install -y` is now default and will be removed  
> > INFO: use --ignore-dependencies to install only the gems you list  
> > ERROR: Error installing chef:  
> > mixlib-authentication requires mixlib-log (\>= 0, runtime)
> > 
> > Clearly it resolved that chef needs mixlib-authentication but then it  
> > couldn't find mixlib-log ?? But that is there and you can install it  
> > explicitly, but only if you don't pass --pre
> > 
> > k@t5400:~$ sudo gem install mixlib-log --pre  
> > ERROR: could not find gem mixlib-log locally or in a repository
> > 
> > k@t5400:~$ sudo gem install mixlib-log  
> > Successfully installed mixlib-log-1.3.0  
> > 1 gem installed  
> > Installing ri documentation for mixlib-log-1.3.0...  
> > Installing RDoc documentation for mixlib-log-1.3.0...
> > 
> > Maybe most folks upgraded from chef 0.9x so they didn't notice, but  
> > this is irritating. Seems like I have to manually specify all the  
> > dependencies that don't have a prerelease version first and then I can  
> > install chef --pre? I know this will go away once all the chef bits  
> > aren't in prerelease anymore, but if this is a gem weirdness, it'll  
> > just keep happening. On the other hand, I might just be missing  
> > something that would make this a non-issue.
> > 
> > KC
> 
> --  
> Opscode, Inc.  
> Adam Jacob, Chief Product Officer  
> T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)

--  
Mark J. Reed [markjreed@gmail.com](mailto:markjreed@gmail.com)

---

<div class="post-metadata">

**Author:** ![KC\_Braunschweig](https://avatars.discourse-cdn.com/v4/letter/k/ea5d25/32.png) [@KC\_Braunschweig](https://discourse.chef.io/u/KC_Braunschweig)\
**Post date:** [April 20, 2011, 7:07pm UTC](https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779/4 "2011-04-20T19:07:37Z")

</div>

kc@t5400:~$ ruby -v  
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86\_64-linux]

kc@t5400:~$ gem -v  
1.3.5

On Tue, Apr 19, 2011 at 5:17 PM, Mark J. Reed [markjreed@gmail.com](mailto:markjreed@gmail.com) wrote:

> That might make sense on RHEL \<= 5, but Ubuntu 10.04 comes with a  
> pretty recent ruby - your choice of 1.8.7 or 1.9.2, IIRC.
> 
> On Tuesday, April 19, 2011, Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:
> 
> > What version of ruby are you using, KC? I think this is actually  
> > caused by Rubygems no longer supporting particular versions of ruby.
> > 
> > Adam
> > 
> > On Tue, Apr 19, 2011 at 4:41 PM, KC Braunschweig  
> > [kcbraunschweig@gmail.com](mailto:kcbraunschweig@gmail.com) wrote:
> > 
> > > Am I missing something here? I've tried a few times now doing a clean  
> > > install of chef only for client install purposes on both RHEL and  
> > > ubuntu (10.04) using rubygems. It seems that it when installing a  
> > > prerelease version, you can't find second level dependencies or  
> > > something like that?
> > > 
> > > Specifically you get things like:
> > > 
> > > kc@t5400:~$ sudo gem install chef --pre -y  
> > > INFO: `gem install -y` is now default and will be removed  
> > > INFO: use --ignore-dependencies to install only the gems you list  
> > > ERROR: Error installing chef:  
> > > mixlib-authentication requires mixlib-log (\>= 0, runtime)
> > > 
> > > Clearly it resolved that chef needs mixlib-authentication but then it  
> > > couldn't find mixlib-log ?? But that is there and you can install it  
> > > explicitly, but only if you don't pass --pre
> > > 
> > > k@t5400:~$ sudo gem install mixlib-log --pre  
> > > ERROR: could not find gem mixlib-log locally or in a repository
> > > 
> > > k@t5400:~$ sudo gem install mixlib-log  
> > > Successfully installed mixlib-log-1.3.0  
> > > 1 gem installed  
> > > Installing ri documentation for mixlib-log-1.3.0...  
> > > Installing RDoc documentation for mixlib-log-1.3.0...
> > > 
> > > Maybe most folks upgraded from chef 0.9x so they didn't notice, but  
> > > this is irritating. Seems like I have to manually specify all the  
> > > dependencies that don't have a prerelease version first and then I can  
> > > install chef --pre? I know this will go away once all the chef bits  
> > > aren't in prerelease anymore, but if this is a gem weirdness, it'll  
> > > just keep happening. On the other hand, I might just be missing  
> > > something that would make this a non-issue.
> > > 
> > > KC
> > 
> > --  
> > Opscode, Inc.  
> > Adam Jacob, Chief Product Officer  
> > T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)
> 
> --  
> Mark J. Reed [markjreed@gmail.com](mailto:markjreed@gmail.com)

---

<div class="post-metadata">

**Author:** ![Adam\_Jacob](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/adam_jacob/32/292_2.png) [@Adam\_Jacob](https://discourse.chef.io/u/Adam_Jacob)\
**Post date:** [April 20, 2011, 9:28pm UTC](https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779/5 "2011-04-20T21:28:52Z")

</div>

I believe you need to upgrade rubygems - can you tell me what happens  
if you do a gem update --system?

On Wed, Apr 20, 2011 at 12:07 PM, KC Braunschweig  
[kcbraunschweig@gmail.com](mailto:kcbraunschweig@gmail.com) wrote:

> kc@t5400:~$ ruby -v  
> ruby 1.8.7 (2010-01-10 patchlevel 249) [x86\_64-linux]
> 
> kc@t5400:~$ gem -v  
> 1.3.5
> 
> On Tue, Apr 19, 2011 at 5:17 PM, Mark J. Reed [markjreed@gmail.com](mailto:markjreed@gmail.com) wrote:
> 
> > That might make sense on RHEL \<= 5, but Ubuntu 10.04 comes with a  
> > pretty recent ruby - your choice of 1.8.7 or 1.9.2, IIRC.
> > 
> > On Tuesday, April 19, 2011, Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:
> > 
> > > What version of ruby are you using, KC? I think this is actually  
> > > caused by Rubygems no longer supporting particular versions of ruby.
> > > 
> > > Adam
> > > 
> > > On Tue, Apr 19, 2011 at 4:41 PM, KC Braunschweig  
> > > [kcbraunschweig@gmail.com](mailto:kcbraunschweig@gmail.com) wrote:
> > > 
> > > > Am I missing something here? I've tried a few times now doing a clean  
> > > > install of chef only for client install purposes on both RHEL and  
> > > > ubuntu (10.04) using rubygems. It seems that it when installing a  
> > > > prerelease version, you can't find second level dependencies or  
> > > > something like that?
> > > > 
> > > > Specifically you get things like:
> > > > 
> > > > kc@t5400:~$ sudo gem install chef --pre -y  
> > > > INFO: `gem install -y` is now default and will be removed  
> > > > INFO: use --ignore-dependencies to install only the gems you list  
> > > > ERROR: Error installing chef:  
> > > > mixlib-authentication requires mixlib-log (\>= 0, runtime)
> > > > 
> > > > Clearly it resolved that chef needs mixlib-authentication but then it  
> > > > couldn't find mixlib-log ?? But that is there and you can install it  
> > > > explicitly, but only if you don't pass --pre
> > > > 
> > > > k@t5400:~$ sudo gem install mixlib-log --pre  
> > > > ERROR: could not find gem mixlib-log locally or in a repository
> > > > 
> > > > k@t5400:~$ sudo gem install mixlib-log  
> > > > Successfully installed mixlib-log-1.3.0  
> > > > 1 gem installed  
> > > > Installing ri documentation for mixlib-log-1.3.0...  
> > > > Installing RDoc documentation for mixlib-log-1.3.0...
> > > > 
> > > > Maybe most folks upgraded from chef 0.9x so they didn't notice, but  
> > > > this is irritating. Seems like I have to manually specify all the  
> > > > dependencies that don't have a prerelease version first and then I can  
> > > > install chef --pre? I know this will go away once all the chef bits  
> > > > aren't in prerelease anymore, but if this is a gem weirdness, it'll  
> > > > just keep happening. On the other hand, I might just be missing  
> > > > something that would make this a non-issue.
> > > > 
> > > > KC
> > > 
> > > --  
> > > Opscode, Inc.  
> > > Adam Jacob, Chief Product Officer  
> > > T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)
> > 
> > --  
> > Mark J. Reed [markjreed@gmail.com](mailto:markjreed@gmail.com)

--  
Opscode, Inc.  
Adam Jacob, Chief Product Officer  
T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)

---

<div class="post-metadata">

**Author:** ![KC\_Braunschweig](https://avatars.discourse-cdn.com/v4/letter/k/ea5d25/32.png) [@KC\_Braunschweig](https://discourse.chef.io/u/KC_Braunschweig)\
**Post date:** [April 20, 2011, 10:51pm UTC](https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779/6 "2011-04-20T22:51:32Z")

</div>

What version of rubygems is required?

ERROR: While executing gem ... (RuntimeError)  
gem update --system is disabled on Debian. RubyGems can be updated  
using the official Debian repositories by aptitude or apt-get.

On Wed, Apr 20, 2011 at 2:28 PM, Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:

> I believe you need to upgrade rubygems - can you tell me what happens  
> if you do a gem update --system?
> 
> On Wed, Apr 20, 2011 at 12:07 PM, KC Braunschweig  
> [kcbraunschweig@gmail.com](mailto:kcbraunschweig@gmail.com) wrote:
> 
> > kc@t5400:~$ ruby -v  
> > ruby 1.8.7 (2010-01-10 patchlevel 249) [x86\_64-linux]
> > 
> > kc@t5400:~$ gem -v  
> > 1.3.5
> > 
> > On Tue, Apr 19, 2011 at 5:17 PM, Mark J. Reed [markjreed@gmail.com](mailto:markjreed@gmail.com) wrote:
> > 
> > > That might make sense on RHEL \<= 5, but Ubuntu 10.04 comes with a  
> > > pretty recent ruby - your choice of 1.8.7 or 1.9.2, IIRC.
> > > 
> > > On Tuesday, April 19, 2011, Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:
> > > 
> > > > What version of ruby are you using, KC? I think this is actually  
> > > > caused by Rubygems no longer supporting particular versions of ruby.
> > > > 
> > > > Adam
> > > > 
> > > > On Tue, Apr 19, 2011 at 4:41 PM, KC Braunschweig  
> > > > [kcbraunschweig@gmail.com](mailto:kcbraunschweig@gmail.com) wrote:
> > > > 
> > > > > Am I missing something here? I've tried a few times now doing a clean  
> > > > > install of chef only for client install purposes on both RHEL and  
> > > > > ubuntu (10.04) using rubygems. It seems that it when installing a  
> > > > > prerelease version, you can't find second level dependencies or  
> > > > > something like that?
> > > > > 
> > > > > Specifically you get things like:
> > > > > 
> > > > > kc@t5400:~$ sudo gem install chef --pre -y  
> > > > > INFO: `gem install -y` is now default and will be removed  
> > > > > INFO: use --ignore-dependencies to install only the gems you list  
> > > > > ERROR: Error installing chef:  
> > > > > mixlib-authentication requires mixlib-log (\>= 0, runtime)
> > > > > 
> > > > > Clearly it resolved that chef needs mixlib-authentication but then it  
> > > > > couldn't find mixlib-log ?? But that is there and you can install it  
> > > > > explicitly, but only if you don't pass --pre
> > > > > 
> > > > > k@t5400:~$ sudo gem install mixlib-log --pre  
> > > > > ERROR: could not find gem mixlib-log locally or in a repository
> > > > > 
> > > > > k@t5400:~$ sudo gem install mixlib-log  
> > > > > Successfully installed mixlib-log-1.3.0  
> > > > > 1 gem installed  
> > > > > Installing ri documentation for mixlib-log-1.3.0...  
> > > > > Installing RDoc documentation for mixlib-log-1.3.0...
> > > > > 
> > > > > Maybe most folks upgraded from chef 0.9x so they didn't notice, but  
> > > > > this is irritating. Seems like I have to manually specify all the  
> > > > > dependencies that don't have a prerelease version first and then I can  
> > > > > install chef --pre? I know this will go away once all the chef bits  
> > > > > aren't in prerelease anymore, but if this is a gem weirdness, it'll  
> > > > > just keep happening. On the other hand, I might just be missing  
> > > > > something that would make this a non-issue.
> > > > > 
> > > > > KC
> > > > 
> > > > --  
> > > > Opscode, Inc.  
> > > > Adam Jacob, Chief Product Officer  
> > > > T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)
> > > 
> > > --  
> > > Mark J. Reed [markjreed@gmail.com](mailto:markjreed@gmail.com)
> 
> --  
> Opscode, Inc.  
> Adam Jacob, Chief Product Officer  
> T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)

---

<div class="post-metadata">

**Author:** ![Stephen\_Nelson\_Smith](https://avatars.discourse-cdn.com/v4/letter/s/eada6e/32.png) [@Stephen\_Nelson\_Smith](https://discourse.chef.io/u/Stephen_Nelson_Smith)\
**Post date:** [April 20, 2011, 11:00pm UTC](https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779/7 "2011-04-20T23:00:29Z")

</div>

On 20 April 2011 23:51, KC Braunschweig [kcbraunschweig@gmail.com](mailto:kcbraunschweig@gmail.com) wrote:

> What version of rubygems is required?

Forget 1.3.5 it's about a bazillion years old. Gem update --system  
will get you the latest (1.7.2 I think)

> ERROR: While executing gem ... (RuntimeError)  
> gem update --system is disabled on Debian. RubyGems can be updated  
> using the official Debian repositories by aptitude or apt-get.

REALLY\_GEM\_UPDATE\_SYSTEM=yes  
export $REALLY\_GEM\_UPDATE\_SYSTEM  
gem update --system

Remind me - is this for a workstation? You might like to try using  
RVM and 1.9.2 if it is.

## S.

Stephen Nelson-Smith,  
Principal Consultant,  
Atalanta Systems Ltd,  
Web: [http://agilesysadmin.net](http://agilesysadmin.net)  
Twitter: @lordcope  
Skype: atalanta.systems  
Telephone: +44 (0) 1223 969819  
Mobile: +44 (0) 7917 101919

Atalanta Systems: The Agile Infrastructure Enablers  
[http://atalanta-systems.com](http://atalanta-systems.com)

---

<div class="post-metadata">

**Author:** ![KC\_Braunschweig](https://avatars.discourse-cdn.com/v4/letter/k/ea5d25/32.png) [@KC\_Braunschweig](https://discourse.chef.io/u/KC_Braunschweig)\
**Post date:** [April 20, 2011, 11:13pm UTC](https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779/8 "2011-04-20T23:13:50Z")

</div>

> **[Chef Support for Automation & DevOps | Chef](https://www.chef.io/support)**
>
> Need help? Get in touch with the Chef Support team via email, social media, or support ticket. Learn more about how to find the right Chef support for your needs.

Ruby 1.8.5, 1.8.6, 1.8.7, 1.9.1 or 1.9.2 with SSL bindings is required.

Rubygems Version 1.3.5 or greater. On Ubuntu and Debian Rubygems  
should be installed from source.

Clearly I didn't follow directions and tried to use standard ubuntu  
rubygems. That being said, am I an asshole for thinking that  
specifying installing from source is pretty lame? Seems like it is  
going to be nothing but pain trying to justify (in a corporate env) a  
tool that doesn't either (1) work with the default platform packages  
(of specified version) or (2) have vendor provided packages for the  
supported OSs that are suitable replacements where there default  
platform packages can't be used. Yes, I can build rubygems from source  
and roll my own package (as the Aegis guys have so helpfully done  
recently for rhel/centos) but it seems like that is just creating  
unnecessary barriers to entry for folks.

KC

On Wed, Apr 20, 2011 at 4:00 PM, Stephen Nelson-Smith  
[stephen@atalanta-systems.com](mailto:stephen@atalanta-systems.com) wrote:

> On 20 April 2011 23:51, KC Braunschweig [kcbraunschweig@gmail.com](mailto:kcbraunschweig@gmail.com) wrote:
> 
> > What version of rubygems is required?
> 
> Forget 1.3.5 it's about a bazillion years old. Gem update --system  
> will get you the latest (1.7.2 I think)
> 
> > ERROR: While executing gem ... (RuntimeError)  
> > gem update --system is disabled on Debian. RubyGems can be updated  
> > using the official Debian repositories by aptitude or apt-get.
> 
> REALLY\_GEM\_UPDATE\_SYSTEM=yes  
> export $REALLY\_GEM\_UPDATE\_SYSTEM  
> gem update --system
> 
> Remind me - is this for a workstation? You might like to try using  
> RVM and 1.9.2 if it is.
> 
> ## S.
> 
> Stephen Nelson-Smith,  
> Principal Consultant,  
> Atalanta Systems Ltd,  
> Web: [http://agilesysadmin.net](http://agilesysadmin.net)  
> Twitter: @lordcope  
> Skype: atalanta.systems  
> Telephone: +44 (0) 1223 969819  
> Mobile: +44 (0) 7917 101919
> 
> Atalanta Systems: The Agile Infrastructure Enablers  
> [http://atalanta-systems.com](http://atalanta-systems.com)

---

<div class="post-metadata">

**Author:** ![Bryan\_McLellan](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/bryan_mclellan/32/81_2.png) [@Bryan\_McLellan](https://discourse.chef.io/u/Bryan_McLellan)\
**Post date:** [April 20, 2011, 11:26pm UTC](https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779/9 "2011-04-20T23:26:33Z")

</div>

On Wed, Apr 20, 2011 at 4:13 PM, KC Braunschweig  
[kcbraunschweig@gmail.com](mailto:kcbraunschweig@gmail.com) wrote:

> Clearly I didn't follow directions and tried to use standard ubuntu  
> rubygems. That being said, am I an asshole for thinking that  
> specifying installing from source is pretty lame? Seems like it is  
> going to be nothing but pain trying to justify (in a corporate env) a  
> tool that doesn't either (1) work with the default platform packages  
> (of specified version) or (2) have vendor provided packages for the  
> supported OSs that are suitable replacements where there default  
> platform packages can't be used. Yes, I can build rubygems from source  
> and roll my own package (as the Aegis guys have so helpfully done  
> recently for rhel/centos) but it seems like that is just creating  
> unnecessary barriers to entry for folks.

We do provide deb packages in our apt repository for those who don't  
want to install from source. [1]

However, Chef 0.10 isn't released yet; and we're still at the release  
candidate stage. The expectation for beta and RC releases is that  
users are not going to install them directly into a production  
environment. It is the period where we all test the software ourselves  
and try to find any major bugs in the new release. If you don't want  
the hassle of building a development environment, I'd advise sticking  
with the official releases. Shortly after the official final release  
of 0.10.0, we'll be putting up apt packages for 0.10, as described  
recently on the Opscode blog [2]. I'm actually working on them right  
now.

In either case, it isn't that you need a newer version of Rubygems for  
Chef 0.10, it is that older versions of Rubygems presumably aren't as  
good at resolving dependencies when using "--pre" to fetch  
prereleases.

Bryan

[1] [http://wiki.opscode.com/display/chef/Package+Installation+on+Debian+and+Ubuntu](http://wiki.opscode.com/display/chef/Package+Installation+on+Debian+and+Ubuntu)  
[2] [Chef 0.9.16 and Ohai 0.6.2 Debian packages available - Chef Blog | Chef](http://www.opscode.com/blog/2011/04/20/chef-0-9-16-and-ohai-0-6-2-debian-packages-available/)

---

<div class="post-metadata">

**Author:** ![KC\_Braunschweig](https://avatars.discourse-cdn.com/v4/letter/k/ea5d25/32.png) [@KC\_Braunschweig](https://discourse.chef.io/u/KC_Braunschweig)\
**Post date:** [April 20, 2011, 11:35pm UTC](https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779/10 "2011-04-20T23:35:35Z")

</div>

> We do provide deb packages in our apt repository for those who don't  
> want to install from source. [1]
> 
> However, Chef 0.10 isn't released yet; and we're still at the release  
> candidate stage. The expectation for beta and RC releases is that  
> users are not going to install them directly into a production  
> environment. It is the period where we all test the software ourselves  
> and try to find any major bugs in the new release. If you don't want  
> the hassle of building a development environment, I'd advise sticking  
> with the official releases. Shortly after the official final release  
> of 0.10.0, we'll be putting up apt packages for 0.10, as described  
> recently on the Opscode blog [2]. I'm actually working on them right  
> now.
> 
> In either case, it isn't that you need a newer version of Rubygems for  
> Chef 0.10, it is that older versions of Rubygems presumably aren't as  
> good at resolving dependencies when using "--pre" to fetch  
> prereleases.

Totally understood regarding chef 0.10 and all beta/RC releases for  
that matter.

My question was meant more generally as the requirements on that page  
(specifically recommending source installed rubygems on ubuntu and  
debian) are general chef requirements, not chef 0.10 specific. While I  
wouldn't have hit this particular issue had I been installing a non  
prerelease version, assumably I would have hit some issue or other or  
else you wouldn't be recommending installing rubygems from source for  
all versions.

KC

---

<div class="post-metadata">

**Author:** ![Adam\_Jacob](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/adam_jacob/32/292_2.png) [@Adam\_Jacob](https://discourse.chef.io/u/Adam_Jacob)\
**Post date:** [April 21, 2011, 4:53am UTC](https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779/11 "2011-04-21T04:53:43Z")

</div>

On Wed, Apr 20, 2011 at 4:35 PM, KC Braunschweig  
[kcbraunschweig@gmail.com](mailto:kcbraunschweig@gmail.com) wrote:

> Totally understood regarding chef 0.10 and all beta/RC releases for  
> that matter.
> 
> My question was meant more generally as the requirements on that page  
> (specifically recommending source installed rubygems on ubuntu and  
> debian) are general chef requirements, not chef 0.10 specific. While I  
> wouldn't have hit this particular issue had I been installing a non  
> prerelease version, assumably I would have hit some issue or other or  
> else you wouldn't be recommending installing rubygems from source for  
> all versions.

The deal here is that Debian and Ubuntu make a series of policy  
decisions about how to structure the libraries they ship with the  
operating system. That's cool - it's the reason distributions exist,  
after all. Next to that is the evolving ruby ecosystem - ruby itself  
moves forward, bugs are fixed, and rubygems continues to become the  
most common way to build and deploy ruby applications. Occasionally  
those policy decisions conflict - in this case, Debian and Ubuntu both  
ship with old versions of rubygems that also have tweaked library  
paths from the norm (specifically, there is an issue with where  
binaries are placed.)

So we make choices - in this case, we advise people to no longer run  
the debian/ubuntu version of rubygems, and we work to get a change in  
policy. That takes time, and so in the mean-time we guide people down  
the path we know will result in a system that behaves as you would  
expect.

The future solution to this problem will be full-stack installers  
delivered both as stand-alone installable binaries and native  
packages, but with the entire dependency chain included. That this is  
the right solution is starting to be pretty widely embraced - you can  
see the evidence in several past package maintainers for chef moving  
to a model exactly like this.

Best,  
Adam

--  
Opscode, Inc.  
Adam Jacob, Chief Product Officer  
T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)

---

<div class="post-metadata">

**Author:** ![KC\_Braunschweig](https://avatars.discourse-cdn.com/v4/letter/k/ea5d25/32.png) [@KC\_Braunschweig](https://discourse.chef.io/u/KC_Braunschweig)\
**Post date:** [April 21, 2011, 5:27am UTC](https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779/12 "2011-04-21T05:27:32Z")

</div>

On Wed, Apr 20, 2011 at 9:53 PM, Adam Jacob [adam@opscode.com](mailto:adam@opscode.com) wrote:

> The future solution to this problem will be full-stack installers  
> delivered both as stand-alone installable binaries and native  
> packages, but with the entire dependency chain included. That this is  
> the right solution is starting to be pretty widely embraced - you can  
> see the evidence in several past package maintainers for chef moving  
> to a model exactly like this.

That's exactly what I was hoping for. Is there a particular person or  
group or wiki page specific to this effort? I definitely want to keep  
up on the progress and hopefully help out if I can.

KC

---

<div class="post-metadata">

**Author:** ![Adam\_Jacob](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/adam_jacob/32/292_2.png) [@Adam\_Jacob](https://discourse.chef.io/u/Adam_Jacob)\
**Post date:** [April 21, 2011, 5:34am UTC](https://discourse.chef.io/t/chef-client-gem-install-pre-doesnt-find-second-level-dependencies/1779/13 "2011-04-21T05:34:26Z")

</div>

On Wed, Apr 20, 2011 at 10:27 PM, KC Braunschweig  
[kcbraunschweig@gmail.com](mailto:kcbraunschweig@gmail.com) wrote:

> That's exactly what I was hoping for. Is there a particular person or  
> group or wiki page specific to this effort? I definitely want to keep  
> up on the progress and hopefully help out if I can.

The Opscode effort can be found here:

[https://github.com/adamhjk/fatty](https://github.com/adamhjk/fatty)

You can find several other efforts (all of which are great):

This one uses RVM, and we've used it successfully with some customers:

> **[GitHub - atomic-penguin/chef-fat-installer: chef-client just-in-time installer](https://github.com/atomic-penguin/chef-fat-installer)**
>
> chef-client just-in-time installer. Contribute to atomic-penguin/chef-fat-installer development by creating an account on GitHub.

The illustrious Matthew Kent has an excellent RVM based system for  
CentOS as well:

> **[GitHub - mdkent/chef-el-rvm-bootstrap: Chef Enterprise Linux RVM Bootstrap](https://github.com/mdkent/chef-el-rvm-bootstrap)**
>
> Chef Enterprise Linux RVM Bootstrap. Contribute to mdkent/chef-el-rvm-bootstrap development by creating an account on GitHub.

I'll get more data sent to the list about timing for an RC of the  
Opscode built binaries.

Adam

--  
Opscode, Inc.  
Adam Jacob, Chief Product Officer  
T: (206) 619-7151 E: [adam@opscode.com](mailto:adam@opscode.com)