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.
Stow is a symlink-kludge.
Much nicer to add amiga-style assigns to the filesystem.
Assigns are like PATH env-vars, but part of the filesystem.
Stow doesn't do dependencies. IMO, that's fine for local package management, where dependency handling is often more trouble than it's worth. (A local package will typically be run on a know configuration, and can target that configuration.)
Do some homework? You are aware that stow has been around since 1996, right? It's amazing how many gentoo fanboys don't know what else is out there.
I have more faith in GNU Autopackage myself.
Or as everybody else refers to it... ~
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 has no concept of dependencies. There is no way you could use it to build a distribution on top of it.
I use stow on my (Debian) Linux PC at home, to manage the software I build from source. If I want to upgrade a program, I can just delete the directory and install the new version in the same location. If a Debian packages becomes available, I remove the directory and have stow remove the links in /usr/local/*.
Until now, I have been able to get all the libraries from Debian, so I never needed to work with dependencies.
WWTTD?
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
For french guys, there is a Stow tutorial in GNU Linux Magazine France of this month (http://www.linuxmag-france.org/). The article is not available online.
Here is the author web site : http://hocwp.free.fr/ln_local/index.html
However I don't recommend his ln_local tool (a simple stow replacement) as it is seriously flawed: this shell script doesn't escape spaces (and other more dangerous shell chars) in filenames when handling them.
Stow is here : http://www.gnu.org/software/stow/stow.html
See also XStow : http://xstow.sourceforge.net/
Dolmen.
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.
In windows, I double-click setup.exe, a GUI pops up, I pick the destination and off it goes.
In Mandrake, I single-click an RPM and the package manager start installing it. Is that easy enough?
Some notes on Windows and Linux package/program installation:
1) Windows setups handle dependancies by basically not handling them. They almost always include a bunch of system DLLs and OCXs that might not be on a user's system or which might be outdated. This obviously leads to much larger packages which for a large part contain stuff that is already on the system. It would be relatively easy on Linux to make every package include every package it depends on. These don't have to be statically linked, you could include the packages for the shared libraries within the main package and have these install automatically. I think the bloat problem would be worse on Linux than Windows, because my feeling is that open source programs tend to use a much wider variety of shared libraries than their proprietary equivalents (where everybody re-invents the wheel on a daily basis because they can't use somebody else's design).
2) Different languages are handled in many cases on Windows by having several setup programs. The main setup.exe in these cases is just a shell that selects which one to run. This adds to package bloat. Linux fares slightly better on this, because (IMHO) i18n is easier on the programmer here.
3) Windows only needs to consider one architecture. If it had several to worry about, we'd probably see a situation much like we have with languages.
4) Configuration at install time on Windows is mostly just choosing which optional extras to install. Most configuration is done within the program itself. This is more-or-less true on Linux as well (for desktop programs at least).
To get close to the Windows installation experience under Linux, what we need to do would be to make every package include every sub-package it depends on and sub-packages for every architecture, disro and langauge. Then you could just download the single file, click it and get everything installed. That package would be enormous however.
Tools like apt-get and urpmi give a very similar experience without the overhead of downloading a bunch of stuff you already have. So long as you stick with stuff that is packaged for you distro, they are painless.
- Blah blah blah, missing scientist. Blah blah blah, atomic bomb. -
> 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
1) It checks dependancies. If dependancies are satisfied it goes to step 2, else it launches the installation of needed packages.
2) It retrieves the app (either sources or binary package, in any format). Some times the portage system simply cannot automatically retrieve the app through the network (apps with required registration or license agreement acceptance requirement). In this case it stops asking the user to manually retrieve the package files, then it continues with the installation.
3) It prepares the app for installation (compiling sources or simply extracting in a temp dir the precompiled binaries (obviously it can deal with every package format)).
4) It installs the app, updating config files.
This way of working simply separates the actual app (source or any other package) from the metadata (contained in the ebuild script). So Gentoo can handle a lot of packets written for other distros (acting as a wrapper), simply trashing the original metadata and substituting it with its own. As a matter of fact writing an ebuild is easier than packaging an rpm.
Signatures are for stupids.
I'd say it's definitely just familiarity.
For anyone confused about the "what goes where" in a Linux system, I warmly recommend taking a look at:
http://www.pathname.com/fhs/
which describes the Filesystem Hierarchy Standard, part of the Linux Standards Base. It should clear things up.
One thing I noticed is that the author of this aritcle installed stow into
I always stow stow itself so that I don't have to mess with paths. Most every OS already points to
The one thing to look out for with stow is "make install" on various packages. I learned to ALWAYS "make -n install" because a lot of packages are broken and don't install into the "prefix". That is, even thought you "configure --prefix=/usr/local/stow/xxxx" the dumb package will still try to put things in
The greatest part of stow is not the installation, it's the deletion. Before I knew about stow, I didn't ever attempt to delete anything in
This:
stow -d
stow -d
Will switch from the old compiler to the new compiler. It's just as easy to switch back to the old compiler if you need to.
Ah. I love stow!
-David
There. Now go play some cool javascript games!
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.
The fork of makepkg used in checkinstall produces broken packages, because it uses the wrong version of tar. This packs files differently, and it DOES make a difference.
As soon as checkinstall uses Slackware's native makepkg by default on Slackware I'll be inclined to recommend it. Still, it's misleading to users of other versions of Linux who might think they are building correct Slackware packages and aren't. I did commit one patch to installpkg to detect and correct for the most common problem with non-standard packages, but can't correct for them all.
Pat