On Apr 22, 2006, at 04:04 AM, Calle D. wrote:
Not to knock the way you admin your systems, but that opinion is not
universal among Unix sysadmins. Some (me, for example) keep /usr/local
for things we’ve installed manually, and really don’t like it if some
packaging system decides to stomp all over them.
This, of course, is why I don’t use packaging systems on any of my OS
X boxes. RedHat is a different story, since the entire OS is
maintained though a package system, but I don’t admin any RedHat
boxes. We’ve got actual RedHat admin experts here at Dartmouth.
Also, having each packaging system use its own hierarchy makes it
possible to have more than one of them installed. Using both
DarwinPorts and Fink works fine today, since one lives in /opt/local
and one in /sw/fink. If they both tried to live in /usr/local, it
would not work so well.
Good point. I actually didn’t know that they did that. But, as I’ve
said, I’m not a real sys admin and I’ve never used package systems
under OS X. I just don’t have that many extra things installed. And
for those that I do, it’s really not that hard to build them from
scratch. In most cases it’s just 3 or 4 commands on the command line.
I was about to start looking at Capistrano for deployment at work. If
it has problems with Ruby being installed in different places on
different machines, I may not bother. How big a problem is it, really?
This depends on the shell that you use for SSH and how that shell’s
default PATH variable is set. If the default PATH doesn’t look in /
usr/local/ (or where ever) first, then you’re going to run into
problems. There are three ways to get around this:
- Replace the /usr/bin/ruby with a symlink
- Enable the SSH flag that lets you set ENV vars on non-login
sessions (which is what cap uses)
- Recompile the shell you use to have a different default PATH
There are plenty of pros and cons to each of these. For the
production Rails Xserve we use at Dartmouth, we went with the second
option (which has worked flawlessly). If that server had more than
4-5 actual user logins, we probably would have gone with the first,
because there are some security implications when you go with the
second. We never really considered going with the third option, but
that might appeal to some…