Hi all, Does anyone know where I can get a new MacOS X package with puppet...? The newest one on reductivelabs site is 0.23.0... -- Med venlig hilsen Juri Rischel Jensen Fab:IT ApS Vesterbrogade 50 DK-1620 København Tlf: 70 202 407 / Fax: 33 313 640 www.fab-it.dk / juri@fab-it.dk
On 9/19/07, Juri Rischel Jensen <juri@fab-it.dk> wrote:> Hi all, > > Does anyone know where I can get a new MacOS X package with > puppet...? The newest one on reductivelabs site is 0.23.0...Hi Juri. I was actually going to take this on, but two things have gotten in the way, firstly some changes in 10.5 and me not wanting to have to re-do the pkgs when it is released... and secondly me being dragged away to a training course this week. I was actually going to see what everyone else thought about where the pkgs should install to on OS X as well. Should it be: 1) The Ruby sitelibdir ? 2) /usr/lib/ruby/site_ruby/1.8 The current packages do 2), but it''s possible to be in a situation where 1) and 2) are not the same... -- Nigel Kersten MacOps @ Google "Two kinds of Kool-Aid"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 20 September 2007, Nigel Kersten wrote:> I was actually going to see what everyone else thought about where the > pkgs should install to on OS X as well. Should it be: > > 1) The Ruby sitelibdir ? > 2) /usr/lib/ruby/site_ruby/1.8 > > The current packages do 2), but it''s possible to be in a situation > where 1) and 2) are not the same...According to the FSH, third party vendor packages should install to /opt. Of course -- OS-X being different, and installing ruby stuff outside its usual search path being unwieldy -- $rubysitedir (there is a facter fact) is probably ok enough. Hardcoding /usr/lib/ruby/site_ruby/1.8/ on the other hand combines -- in the worst case -- the unwieldiness of a directory outside of ruby''s search path with a non-standard location outside /opt or /usr/local. Regards, David - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG8g/I/Pp1N6Uzh0URAheUAKCQ6q0JviPXqeYS66wEdlT65PY4XQCgmDFd BlC4d2l6KO+AXNd+TmoS1u0=GPCh -----END PGP SIGNATURE-----
On 9/19/07, David Schmitt <david@schmitt.edv-bus.at> wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thursday 20 September 2007, Nigel Kersten wrote: > > I was actually going to see what everyone else thought about where the > > pkgs should install to on OS X as well. Should it be: > > > > 1) The Ruby sitelibdir ? > > 2) /usr/lib/ruby/site_ruby/1.8 > > > > The current packages do 2), but it''s possible to be in a situation > > where 1) and 2) are not the same... > > According to the FSH, third party vendor packages should install to /opt. Of > course -- OS-X being different, and installing ruby stuff outside its usual > search path being unwieldy -- $rubysitedir (there is a facter fact) is > probably ok enough. > > Hardcoding /usr/lib/ruby/site_ruby/1.8/ on the other hand combines -- in the > worst case -- the unwieldiness of a directory outside of ruby''s search path > with a non-standard location outside /opt or /usr/local.So to complicate things further :) It''s possible to do install straight to sitelibdir, but you kind of have to do it with a nasty hack due to the limitations of the pkg format not allowing dynamic install locations. ie, you install to /tmp/some-predicatable-location and as a preinstall script you create that as a symlink pointing to sitelibdir. The downside of this (other than offending me at a fundamental level) is that you then lose all ability to query the BOM of the pkg to work out where the files were actually installed. I should mention that the path I quoted in 2) is actually inside ruby''s search path in OS X 10.4, and should be in 10.5, but the new framework complicates this a little, so it''s not quite as bad as you''re describing. -- Nigel Kersten MacOps @ Google "Two kinds of Kool-Aid"