Manage Packages Using Stow 234
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."
Stow isn't Perfect, alas... (Score:5, Informative)
well... (Score:5, Informative)
Re:Stow isn't Perfect, alas... (Score:5, Informative)
http://encap.cso.uiuc.edu
Re:Stow isn't Perfect, alas... (Score:5, Informative)
I'm not exactly sure what you're unhappy with, but it sounds like a build problem rather than a stow problem, IMHO. With stow you can build the program to expect either the "real" path, or the "stowed" path, depending on your purposes. (Using the "real" path means that multiple versions can be installed in the stow tree and used simultaneously with an explicit path, while using the "stowed" path means that things like config files are in an expected location like "/usr/local/etc".)
Rather Amiga assigns (Score:1, Informative)
Much nicer to add amiga-style assigns to the filesystem.
Assigns are like PATH env-vars, but part of the filesystem.
Re:What about dependencies? (Score:3, Informative)
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.
What about autopackage? (Score:1, Informative)
Re:Unix Directory Structures (Score:3, Informative)
Encap is better (Score:4, Informative)
Also, cpanencap [uiuc.edu] is the perfect tool for perfecting Perl's module system. All it needed was versioning.
It doesn't (Score:3, Informative)
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.
Re:How does Stow handle dependencies? (Score:4, Informative)
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`
remember this when deciding to try out stow (Score:5, Informative)
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
Re:Have you tried Gentoo's Emerge (Score:5, Informative)
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
Re:remember this when deciding to try out stow (Score:4, Informative)
Odd. On my system it will notice that bin is a symlink to a bin dir in a different stow package, remove the symlink, create a dir, then link the contents of *both* packages bin dirs into the new
See also Linux Mag France (Score:2, Informative)
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.
Use checkinstall instead (Score:5, Informative)
Checkinstall [izto.org] 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.
SEPP ideal package management (Score:2, Informative)
Re:Why can't it be more like Windows? (Score:2, Informative)
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.
Re:Excuse me? (Score:3, Informative)
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"...
Re:Have you tried Gentoo's Emerge (Score:3, Informative)
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.
Re:Unix Directory Structures (Score:2, Informative)
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.
Stow is great! (Score:2, Informative)
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
Re:Use checkinstall instead (Score:3, Informative)
Slackware packages are not simply tar+gz. It's important that the files are stored into the tar archive in a certain way, the correct version of tar is used, and the symbolic links are moved into the installation script properly, otherwise the package can't be effectively managed. You wouldn't try to make an rpm or deb with tar/cpio/bzip2/gzip/etc, so why people think they can tar up some files and call it a Slackware package is beyond me.
No ... don't use make-install, use configure!!! (Score:4, Informative)
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.
Re:Checkinstall DOES use makepkg (Score:2, Informative)
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