Slashdot Mirror
Manage Packages Using Stow
dW writes "This article is about Stow, a software installation management utility for Linux that offers a number of advantages over the tried-and-true Red Hat and Debian package management systems. With Stow, you can package applications in standard tar files and keep application binaries logically arranged for easy access."
We (the Tcl core developers) have had problems in the past with Stow, mainly because it relies on being able to specify the installation process at 'make-install' time instead of normal 'make' time, leading to messed up baked-in paths... :^/
"Little does he know, but there is no 'I' in 'Idiot'!"
stow is not at all a "package management utility for linux". It's a perl script and runs on almost anything. I've used it to manage local packages on IRIX, Solaris, and various flavors of Linux. IMO, the great strength of stow is exactly local packages--it's a great way to manage a shared /usr/local or such. I suggest thinking of stow as a powerful complement to your native package management scheme.
encap is a better and more established system that works on the same general idea - put everything in /usr/local/encap/PACKAGE-VERSION, and symlink into place. It's mostly just used at UIUC, but good Gods it works well. I use it for absolutely everything, and essentially refuse to install anything on our systems that won't support it. And I have yet to encounter a workplace where it doesn't win over absolutely everyone with its simplicity within six months.
Also, cpanencap is the perfect tool for perfecting Perl's module system. All it needed was versioning.
Stow does not handle dependencies. All it does is use symbolic links so that your packages may install in one directory (completely) and then have symbolic links to a shared directory tree. This was once a standard technique that was manually performed by several system administrators. More recently packaging systems have gained widespread acceptance by people so tools like stow have not been as amazingly handy.
Stow still has importance, though. For example, some people would prefer to build their own application distribution area. This is of particular utility when you have a network of machines and want the same applications available everywhere. Pick a machine and have it NFS share the applications. In these situations Stow still is important. Maybe the stock packaged Perl is not good enough, maybe you want the multithreaded options and a few extra modules from CPAN. Then creating a new Perl directory and stowing it somewhere else is handy.
Stow is not perfect. I have found that it is a bit buggy with its delete operation. I usually erase the directory with the given software and then look for symbolic links that are broken:
/dev/null 2> /tmp/T
ls -lL >
rm `sed s/:.*$//g`
I've used stow on different unix platforms during the last couple of years, and I think it is a great tool to maintain software packages which aren't supported by the platforms own packaging system (deb, rpm, pkg, etc..)
/usr/local, then be sure to make the directory structure:
/usr/local/bin
/usr/local/lib
/usr/local/include
/usr/local/packages/app-1.4
/usr/local/packages/app-1.4/bin /usr/local/packages/app-1.4/lib
/usr/local-structure will result in:
/usr/local
/usr/local wille see that f.x. /usr/local/bin allready exits at then link the files from it's own bin-drectory to /usr/local/bin, which result in files from app2-1.5 will be linked to the /usr/local/packages/app-1.4 structure, which will mess up things.
But remember one thing. If you are starting with a new stow system in f.x.
etc
if it doesn't exit before stowing anything. Otherwise the following will happen. let's asume that you have the software package in:
with it's own strucure like:
etc.
stow'ing this packages without the
ls -l
bin -> packages/app-1.4/bin
lib -> packages/app-1.4/lib
etc.
Then the nect package (let's call it app2-1.5) you will be stow'ing to
Flamebait disclaimer: I have been running Gentoo on all of my machines for over a year now, so don't take this as an anti-Gentoo comment.
/usr. These can start with source (or pre-compiled binaries), and handle everything from installation to dependency-handling, etc (with varying degrees of efficiency).
/usr/local, for those apps I compile and install manually (and, for whatever reason, don't want to repackage as an ebuild/rpm/whatever)
:)
stow and ebuilds aren't really operating in the same space.
rpm,deb,portage = full blown package managers, controlling everything under
stow = simple symlink manager, providing an easy way to maintain order within
There are times when one does create one's own ebuilds (v simple) or rpms (slightly more involved). For all other occasions, stow is a helpful tool
Checkinstall automatically produces native packages (rpm, deb, slackware tgz) from a standard make install. I've found this gives the best of both worlds - easy, consistent package management coupled with flexible/optimized source configuration.