1

A common thing for people who work on machines without having root rights is to locally build your own little suit of your favorite tools.

The workflow goes a little something like this:

tar xvzf fav_tool.tar.xvzf
cd fav_tool
./configure --prefix=$HOME
make install

It tends to get a little messy. You get folders like bin/, etc/, include, lib/ and source/ in your home folder. You have to manage dependencies and $PATH. Is there a smart way to do this? Is there tool to keep track of your packages locally?

Joachim
  • 164
  • This is the smart way. What's the problem? If you consider a directory tree a hassle, what on earth are you doing with a computer that requires you to build your own anything? – goldilocks Aug 26 '15 at 08:16
  • There are other examples where people made processes like this easier (especially the simplifying the directory tree). For example homebrew or Vundle. This https://gist.github.com/ryin/3106801 seems less straight-forward then for example brew install tmux. – Joachim Aug 26 '15 at 08:33
  • There's also instant tea. However, I do not believe it can get any simpler than it already is -- just different. There's no point in "simplifying the directory tree". It exactly mirrors a root filesystem (on purpose, for hopefully obvious reasons), so should not be anything but familiar to someone who manages to open a terminal and type make. It is also as simple as a directory tree can get -- one level, and perhaps 2 or 3 folders that are actually used. – goldilocks Aug 26 '15 at 09:06

1 Answers1

2

It tends to get a little messy. You get folders like bin/, etc/, include, lib/ and source/ in your home folder.

By choice, yes. If that seems untidy, you can use

./configure --prefix=$HOME/mytools

Instead. You will then need to add that to your $PATH, or, if $HOME/bin is already part of it, you could move everything currently there into $HOME/mytools/bin and

rm ~/bin
ln -s ~/mytools/bin ~/bin

If your tools put stuff in ~/mytools/lib, you'll also want to set LD_LIBRARY_PATH appropriately somewhere.

If you use whatever initialization file you normally use for setting env variables, this only needs to be done once and takes about a minute to do.

You have to manage dependencies

If by "manage" you mean resolve for the purpose of installation, that is a major purpose of ./configure. If it doesn't do this right, a third party tool is unlikely to do it much better. It might, but it might also do worse.

If you mean something else, there really isn't anything else involved in the concept of "dependency". If you mean you want something that resolves this, downloads the dependency, and installs it for you, that's what normal package managers are for -- but remember you decided you didn't want pre-built binaries. You are building from source.

It is very unfortunate that linux package managers are mostly unfriendly or useless to unprivileged users, but that is a separate issue (and a separate question, to which there are various answers depending on the distro).

Is there tool to keep track of your packages locally?

Yes, the source packages themselves. When you build, unpack in ~/mytools/src. You can leave the build directory there, or just the tarball. When you want to uninstall something, you just go into the relevant directory (unpacking it again if necessary) and make uninstall.

The src directory is never used by the system for anything. It contains only what you put in it, and so as long as you don't delete your downloads, you have a nice tidy list of local installed source built software, with the sources actually used to build it all.

goldilocks
  • 87,661
  • 30
  • 204
  • 262