4 ms·

The clean way to use projects like Redis is to unpack them into an "/opt" directory (either in your home directory or the root file system). Then just `make` wi

The clean way to use projects like Redis is to unpack them into an "/opt" directory (either in your home directory or the root file system). Then just `make` without the install and add that directory to your system path. In that case of Redis, you have to add the Redis `src` subdirectory to the system path in order to be able to use the `redis-server` command. You probably know all this already, but it's really the easiest way to keep track of projects you build yourself. I think there is no `uninstall` command included usually because most packages that are installed using `make install` are system libraries that other packages depend upon. And so just uninstalling that one package could result in a broken system. There may be some other historical reason, but that's my guess. EDIT: Yes, `checkinstall` is a really cool idea, but I've had a hard time getting it to work reliably in practice. Building a deb is a complicated process, so it's not surprising that attempting to automatic that process is not 100% reliable. But you should try it out, maybe you'll have better luck that I did.

e12e 14y ago
I highly recommend using stow/xstow[1]. Pick a place to "stow" your "out-of-band" programs, then: cd <awsome-src-distribution> ./configure --prefix=/usr/local/ && make make install prefix=/usr/local/opt/<awsome-1.2.3> cd /usr/local/opt xstow <awsome-1.2.3> (aptitude install xstow on Debian & Ubuntu) Xstow is also small enough to fit it into eg: ${HOME}/opt -- and it is able to "unstow". [1] http://xstow.sourceforge.net/ http://xstow.sourceforge.net/ edit: formatting
- e12e 14y ago
  To clarify; what (x) stow does, is manage a set of symlinks from/in eg: /usr or /usr/local to a similar tree under eg: /usr/local/<program-version/, so that for instance: /usr/local/bin/<program> -> /usr/local/<program-version>/bin/<program> Similarly for man, lib etc. If you don't put stuff under /usr or /usr/local (but, say under /opt or ${HOME}/opt) -- you need to update your paths (PATH, MANPATH, USER_LD..). Uninstalling just means removing the symlinks (unstow) and deleting the tree under /wherever/<program-version>. This is what I do in my bashrc (which I use across a range of systems, some of which are mine, some of which I only have a user accounts -- some on Solaris, most on a flavour of Linux): # set PATH so it includes user's private bin if it exists for dir in "${HOME}" "${HOME}/opt" "${HOME}/opt/${unps}" do if [ -d "${dir}/bin" ] then PATH="$dir/bin":"${PATH}" fi # For python binaries, in "default" virtenv: if [ -d "${dir}/pybin" ] then PATH="$dir/pybin":"${PATH}" fi # do the same with MANPATH if [ -d "${dir}/man" ] then MANPATH="${dir}/man":"${MANPATH}" fi if [ -d "${dir}/lib" ] then USER_LD_LIBRARY_PATH="${dir}/lib":"${USER_LD_LIBRARY_PATH}" fi if [ -d "${dir}/include" ] then USER_LD_RUN_PATH="${dir}/include":"${USER_LD_RUN_PATH}" fi done #Then later: export PATH MANPATH USER_LD_LIBRARY_PATH USER_LD_RUN_PATH The part about "pybin" is just becaus I do: cd ~/opt mkdir python-venvs virtualenv --no-site-packages python-venvs/misc ln -s python-venvs/misc/bin pybin And can then pip install stuff and have it available without having to worry about activating a virtualenv etc. I generally keep large packages in separate venvs -- but install stuff like mercurial in the "misc" one. Note that the structure of my opt-folder mirrors that of eg. /usr/local, so: mkdir -p ~/opt/{bin,include,lib,man,share} (I also have src and xstow in there -- src for source packages I want to keep around, xstow for xstow-installed packages.) And to repeat, if you put your xstow tree under /usr/local or somewhere most likely already in your path, it should "just work" without having to set any extra variables -- and is more useful for eg: installing a system wide service (like Redis for production use). edit: forgot to add export of environment variables to the .bashrc snippet edit: the "${HOME}/opt/${unps}" points to a directory that contains architecture specific binaries; the unps-variable, is set to be `uname -ps` (with some trickery) -- and is then used for finding local binaries and setting some options like PAGER.
  - codebeaker 14y ago
    Stow seems to have a flavor of Mac homebrew about it (more likely the other way around) everything is compiled and installed into `/Library/Cellar` and then symlinked into the system path, you can `brew unlink readline`, for example and it goes away, link it back and it's available to the system again. The `brew` executable knows about the correct flags to give to `--configure` within it's own context, so it rarely goes wrong.
codebeaker 14y ago
> I think there is no `uninstall` command included usually because most packages that are installed using `make install` are system libraries that other packages depend upon. And so just uninstalling that one package could result in a broken system. There may be some other historical reason, but that's my guess. That's a good point, there is no dependency resolution at this low-level; and with that in mind, there's probably a good way to uninstall things by hand, if you really wanted to.. thanks for the thought.

e12e 14y ago

I highly recommend using stow/xstow[1]. Pick a place to "stow" your "out-of-band" programs, then: cd <awsome-src-distribution> ./configure --prefix=/usr/local/ && make make install prefix=/usr/local/opt/<awsome-1.2.3> cd /usr/local/opt xstow <awsome-1.2.3> (aptitude install xstow on Debian & Ubuntu) Xstow is also small enough to fit it into eg: ${HOME}/opt -- and it is able to "unstow". [1] http://xstow.sourceforge.net/ http://xstow.sourceforge.net/ edit: formatting

e12e 14y ago
To clarify; what (x) stow does, is manage a set of symlinks from/in eg: /usr or /usr/local to a similar tree under eg: /usr/local/<program-version/, so that for instance: /usr/local/bin/<program> -> /usr/local/<program-version>/bin/<program> Similarly for man, lib etc. If you don't put stuff under /usr or /usr/local (but, say under /opt or ${HOME}/opt) -- you need to update your paths (PATH, MANPATH, USER_LD..). Uninstalling just means removing the symlinks (unstow) and deleting the tree under /wherever/<program-version>. This is what I do in my bashrc (which I use across a range of systems, some of which are mine, some of which I only have a user accounts -- some on Solaris, most on a flavour of Linux): # set PATH so it includes user's private bin if it exists for dir in "${HOME}" "${HOME}/opt" "${HOME}/opt/${unps}" do if [ -d "${dir}/bin" ] then PATH="$dir/bin":"${PATH}" fi # For python binaries, in "default" virtenv: if [ -d "${dir}/pybin" ] then PATH="$dir/pybin":"${PATH}" fi # do the same with MANPATH if [ -d "${dir}/man" ] then MANPATH="${dir}/man":"${MANPATH}" fi if [ -d "${dir}/lib" ] then USER_LD_LIBRARY_PATH="${dir}/lib":"${USER_LD_LIBRARY_PATH}" fi if [ -d "${dir}/include" ] then USER_LD_RUN_PATH="${dir}/include":"${USER_LD_RUN_PATH}" fi done #Then later: export PATH MANPATH USER_LD_LIBRARY_PATH USER_LD_RUN_PATH The part about "pybin" is just becaus I do: cd ~/opt mkdir python-venvs virtualenv --no-site-packages python-venvs/misc ln -s python-venvs/misc/bin pybin And can then pip install stuff and have it available without having to worry about activating a virtualenv etc. I generally keep large packages in separate venvs -- but install stuff like mercurial in the "misc" one. Note that the structure of my opt-folder mirrors that of eg. /usr/local, so: mkdir -p ~/opt/{bin,include,lib,man,share} (I also have src and xstow in there -- src for source packages I want to keep around, xstow for xstow-installed packages.) And to repeat, if you put your xstow tree under /usr/local or somewhere most likely already in your path, it should "just work" without having to set any extra variables -- and is more useful for eg: installing a system wide service (like Redis for production use). edit: forgot to add export of environment variables to the .bashrc snippet edit: the "${HOME}/opt/${unps}" points to a directory that contains architecture specific binaries; the unps-variable, is set to be `uname -ps` (with some trickery) -- and is then used for finding local binaries and setting some options like PAGER.
- codebeaker 14y ago
  Stow seems to have a flavor of Mac homebrew about it (more likely the other way around) everything is compiled and installed into `/Library/Cellar` and then symlinked into the system path, you can `brew unlink readline`, for example and it goes away, link it back and it's available to the system again. The `brew` executable knows about the correct flags to give to `--configure` within it's own context, so it rarely goes wrong.

codebeaker 14y ago

> I think there is no `uninstall` command included usually because most packages that are installed using `make install` are system libraries that other packages depend upon. And so just uninstalling that one package could result in a broken system. There may be some other historical reason, but that's my guess. That's a good point, there is no dependency resolution at this low-level; and with that in mind, there's probably a good way to uninstall things by hand, if you really wanted to.. thanks for the thought.