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.
> Could somebody please enlighten me? I don't get the point at all.
.deb, and stow is perfect for that. I have an m68k cross-compiler version of gcc (for Palm(tm) development), a locally modified version of the GTK canvas, and a few other obscure, specialized bits of software, all of which are "stow"-ed. I have realized many of the advantages described in the article -- I can uninstall these things cleanly, and move between versions just by unstowing the old one and stowing the new one.
/etc/init.d, or be configured from a file in the /etc directory. But it *is* very useful for those occasional, obscure bits of software which primarily consist of libraries and include-headers, or non-system executables.
I'll try to give it a go. I have several Debian boxes, and mostly use apt, but every now and then I need to install something for which there is no
I do think the article (and much of the commentary here) overstates the role of stow. It's not a substitute for a package manager, and the way it works makes it unsuitable for system-level software that, for instance, might need to set up cron jobs, require scripts in
Stow itself is not new, and interestingly is packaged by debian -- I got it by "apt-get install stow"...
2*3*3*3*3*11*251
Yes, but that's only a problem with the stow documentation. Use "--prefix=" during configure and you'll have no worries at all (except that the "baked-in" package names will be '/usr/local/stow/yourpackage/etc ...', but that has never mattered to me and I have about fifty stow packages installed on my system, with everything from gtk-2.2 to lyx to rxvt).
I have used stow for the past year and absolutely love it. It allows me to have complete control over all the software I compile by had, as opposed to the base system installed by my distro. And since I have a bash alias to ./configure to include an automatic prefix assignment based on the directory name I'm configuring from (which is almost always based on the name and version number of the software), I can compile a new version and
stow -D /usr/local/stow/foo-1.2
stow /usr/local/stow/foo-1.3
... without losing my old version that I know works. (so, if my new version segfaults, I can "install" the old one simply by reversing the above process)
And ... I can do a simple "du" command in the /usr/local/stow directory to see exactly how much disk-space each package is using and I can easily find, modify or delete a part of a package I compiled months ago!
Stow is one of the most fantastic pieces of software, and it's simplicity itself as well. It reports conflicts and only installs sym-links. The scary thing is that this is the first and only time I have ever seen it reach "mainstream" coverage - like most of the best linux software, it seems to be unheard of and unused.