4 ms·

A few years of systems have given me a really good way for handling this problem (other than the obvious bit of just using whatever packaging system the OS prov

by donw 18y ago

A few years of systems have given me a really good way for handling this problem (other than the obvious bit of just using whatever packaging system the OS provides). I use /opt rather than /usr/local, but you can do either. Build all your packages into /opt/package-version, and set up a symlink from /opt/package to /opt/package-version for whatever you want the default version to be. As an example, Ruby 1.8.7 goes into /opt/ruby-1.8.7, and /opt/ruby points to this directory. The only disadvantage is you need to add each bin/ directory into your path, which will be a problem if you install hundreds of applications in this fashion. On the other hand, being able to do in-place upgrade and rollback almost instantly (just re-point the symlink) is a big, big win in a production environment. Plus, because everything is located in one place, you can readily move your /opt/app-version directory to other systems.

pfaux 18y ago
Yes, essentially I follow the same simple system. But to avoid adding each bin directory to the path, I create for each application an executable script in /usr/local/bin that performs an "exec /opt/package/bin/app-name $@". The only directory to add to the path is /usr/local/bin. Then, as you say, managing multiple application versions is as easy as repointing the symlink in /opt. No need for package managers that do who knows what to your system. The one exception is for shared libraries, which I build to /usr/local. That way 'make' can find them easily without fiddling with LDPATH.
- donw 18y ago
  Why not just do symlinks in /usr/local/bin?
  - pfaux 18y ago
    A script can pass specific environment variables to the particular instance of the application.
njharman 18y ago
I(well really it's make install --prefix=/usr/local/python2.5) do the same thing in /usr/local. I don't see the need or point for /opt. I guess I'm socially unacceptable?
- donw 18y ago
  I like /opt for one big reason: the default path for a lot of packages is /usr/local, so putting things in /opt can help protect them from being accidentally overwritten.

by donw 18y ago

pfaux 18y ago

Yes, essentially I follow the same simple system. But to avoid adding each bin directory to the path, I create for each application an executable script in /usr/local/bin that performs an "exec /opt/package/bin/app-name $@". The only directory to add to the path is /usr/local/bin. Then, as you say, managing multiple application versions is as easy as repointing the symlink in /opt. No need for package managers that do who knows what to your system. The one exception is for shared libraries, which I build to /usr/local. That way 'make' can find them easily without fiddling with LDPATH.

donw 18y ago
Why not just do symlinks in /usr/local/bin?
- pfaux 18y ago
  A script can pass specific environment variables to the particular instance of the application.

njharman 18y ago

I(well really it's make install --prefix=/usr/local/python2.5) do the same thing in /usr/local. I don't see the need or point for /opt. I guess I'm socially unacceptable?

donw 18y ago
I like /opt for one big reason: the default path for a lot of packages is /usr/local, so putting things in /opt can help protect them from being accidentally overwritten.