[chef] Re: Re: Re: Re: Re: Re: Re: Installing from OS Package vs Download

[Jesse Nelson < >]

build it and run your own repo.  Just gotta watch how you build if you want to eventually get back to what upstream is providing.  Most places with a significant amount of machines will be mirroring the repos of whatever distro they use anyhow. 

On Apr 13, 2011, at 11:13 AM, Edward Sargisson wrote:

I was going to ask about that.

Let's say I really need the latest version of something that already exists as a package. (e.g. PostGis for ubuntu is currently 1.5.1 and I might want 1.5.2).

Would I be better to:
a) Run a source build, put the binaries on a file server and write recipes to download and install them.
b) Grab the packaging scripts, attempt to build my own upgrade, place it into a local package repository and contribute the patches back.

What do people normally do?

Cheers,
Edward

On Wed, Apr 13, 2011 at 10:52 AM, KC Braunschweig < "> > wrote:

On Wed, Apr 13, 2011 at 10:37 AM, Seth Chisamore < "> > wrote:
> The 'tomcat' cookbook also supports installation of tomcat 6 via packages on
> centos/rhel systems using the jpackage yum repository.  And as Noah
> mentioned, a separate source and package recipe is a good approach.  The
> 'default' recipe then chooses the appropriate recipe based on platform...or
> you can do a 'hard' override by selecting the appropriate recipe directly.

While this is a reasonable way to install from source if necessary,
I'd discourage anyone from doing this in practice on boxes you care
about (i.e. production systems or dev/qa systems in an enterprise
environment). If there isn't a package for your platform, grab the
source and build the package yourself. You won't get the benefits of
community testing of the build, but you'll still get the benefits of
package management to install, remove and manage dependencies for the
package. Bonus points for contributing your package build back to the
community (shout out to the folks on this list that have published
their chef and chef dependency packages that weren't publicly packaged
before!).

KC