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.
There's a difference between package managers and compression algorithms. Packaging is ever so much more than compressing the files in a hierarchy into one lump...
"Little does he know, but there is no 'I' in 'Idiot'!"
Whilst this is some way towards making Linux more user friendly (and ultimately gaining acceptance on the corporate desktop), what are the chances of anything being done about the crazy directory layout of a *nix system?
If the answer is nothing, then a suitable GUI for Linux that has the objective to gain corporate desktop acceptance really has to isolate the [l]user from this - i.e. with something like "My Documents".
I like using Linux, but even as a seasoned IT pro, the directory structure and "what goes where" of a *nix system still bugs me.
One of the reasons I switched from Redhat 8.1 / 7.3 to Gentoo Linux (Beta) was the amazing Emerge package management tool. It combines simple Tar based package files with cool scripts called eBuilds, that automagically fetch and compile all the components I need.
Of course Gentoo is not for everybody... it takes longer to install than Debian (and that is before you have compiled the entire OS from scratch), but for those who are interested in that sort of thing it can be a refreshing alternative.
The article does not mention anything about dependencies. In my opinion dependencies are almost as important as keeping track of which file belongs to what application. Maybe they should do some more homework and take a look at Gentoo's Portagepackaging system. This system not only compiles a tar/tar.gz/tar.bz2 package, but also retrieves the needed packages (including the dependencies) from their homepages.
You know it makes sense, a little reminder from jointm1k.
I've got some experience with Debian's package management system, and while hard to use for a novice and somewhat complex there is one great benefit: conflict and dependency handling.
Based on the article I didn't quite understand if Stow provides similar services. There were some hints on this, but could someone with experience shed some light on the subject?
.: Max Romantschuk
This has about as much flexibility as distributing binaries in a tarball. You can't include installation/uninstallation scripts (what if my application needs to install a cron job?). Everything is forced into /usr/local/stow/PACKAGEDIR and a mess of symbolic links are used to bump everything into the corresponding bin, lib, include, whatever directories. While it may be easier for the software to manage, it creates countless unnecessary files on your drive.
I don't see the benefit.
In windows, I double-click setup.exe, a GUI pops up, I pick the destination and off it goes. Why can't someone make something like this for Linux? It would greatly improve the user experience in Linux. Instead of having to edit 8 configuration files, the user just starts setup.sh or something and the setup asks questions. This is why I like apt-get - one line setup. But every time I download something that's not part of Debian it turn into a horrible experience I wish I would have never had.
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.
The real answer isn't stow, it's gentoo. Sure you could spend time trying to manage packages. Or you could just use a distro that source compiles everything, manages your packages, and lets you write really simple scripts to contribute back. Of course maybe that's just why I run it.
Must be a slow package managing system ;-) Honestly - I read Slow first time. Then again English is not my native tounge - so I might just be a bit slow.
Simply Throw Out Window ...
Why is that when companies releases something, a GNU friendly user always get the creeps! This is no exception. (This is released under GPL but anyway!)
Let me quote RMS: "Note the distinct difference between free as in freedom and open source as in buzzword"
Girls are strange. They don't come with a man page.
-- Michael Mattsson
There is only one true way: CVS
:)
Everything else is as good as CAB files
I have more faith in GNU Autopackage myself.
1. Stow requires you configure all the packages into their own directory, which will cause problems with Gnome and KDE. Some packages are easy to configure into one directory, eg. /usr/local, and then install into another, eg. /usr/local/stow/packagename. Others, not so much...
2. Stow has a serious bug in the way it handles directories. If only one package touches a certain directory, it simply creates a symlink to the directory. And then if another package puts something there, it then removes the symlink and does the normal thing. This is a good idea, however, Stow borks this up sometimes, which is bad.
If you're interested, there's a program similar to stow, called srcpkg, at tempestgames.com/ryan. Yes, I wrote it, sorry for the blatant plug. I thought it relevent because I wrote it after experiencing said problems with Stow. FYI, I use srcpkg to manage all the non-system software on my machine, including Gnome, KDE, mplayer, ogg, SDL, and a very large number of other libs and programs.
There's also a number of similar programs on freshmeat. They're all tailored to slightly different needs, but they're all generally better than Stow.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
The reason is readily apparent. There is no clean, high-level way to specify installation details to make. Almost always "make install" invokes a messy ad hoc jumble of Bourne shell commands. Make has its own variables. Bourne shell has its variables. You end up double escaping all kinds of items and end up with $$Variables and a plethora of back ticks. The consequence is that install details in a make file tend to look like Perl's uglier cousin. Throw in line extension by escaping line ends with a reverse solidus, and you have the makings of a maintenance nightmare. Try previewing "make install" with "make -n". Not too helpful is it?
How to fix it? I don't know. Perhaps if all Unix vendors could agree on an "installation specification language" -- ISL. Then each vendor's "make" program could incorporate an interperetter for ISL. Other programs like Linux RPM could benefit for this too and incorporate an ISL interpreter because RPM installation specifications are only slightly better than plain Bourne shell (although definitely a step in the right direction).
PLEASE, what should I do with my life ??!
End 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?
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
Redundant? I see no other posts pointing this out. What gives?
The UNIX way of putting applications is well thought out, matured and perfectly fine. Needlessly playing around with it is likely to cause more problems than it solves.
Yes, the package management scene on Linux sucks right now. But it is because of dependency management, and has nothing to do with all the files of an application in a nice folder.
I think more people should take a look at tclkit (http://www.equi4.com/tclkit) and the concept of starkits (http://www.equi4.com/starkit). This is a great concept where an application is delivered as one self-contained file (compressed, with an internal virtual file-system). This gets rid of the problem of "installation" all together.
Very cool stuff.
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.
standard slackware 'installpkg' with 'checkinstall' does the job quite good, besides 'make prefix=/your/path install' breaks a lot of apps
That works fine for a few applications. Linux has thousands of applications, and people tend to install hundreds of them (they are free, after all, so why not). Do you want to go through hundreds of GUI installers, and then hundreds of GUI updaters? I don't.
Why can't someone make something like this for Linux?
There are interactive installers for Linux packages, but they are usually a nuisance compared to a normal package.
But every time I download something that's not part of Debian it turn into a horrible experience I wish I would have never had.
Well, then don't install non-Debian packages. After all, there are plenty of Windows programs that come with horrible installers. As a Debian user, think of non-Debian packages as "programs that come with horrible installers", and then decide whether they are worth the trouble. (Note that you can usually import packages reasonably well via "alien".)
The package system you get with Debian (or RedHat, for that matter) is already so much better than anything you get for Windows that it isn't funny. If Linux developers adopted the equivalent of setup.exe more widely, that be a real blow to Linux.
I don't see what's wrong with that... Personally, I keep a lot of miscellaneous documents in `/home/$user/Docs'.
I can't stand the way in Windows everything is "My" this and "My" that... It's like it's made by Fisher Price for 3rd graders... I guess that would explain the new look in XP :)
Sticking feathers up your butt does not make you a chicken - Tyler Durden
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.
It is good to be able to use independent directories for applications that are installed at the site (i.e. not part of the distribution.) And RPM can accomodate such independent directories as well. Within the independent tree, the applications should standardize the directory structure just like in unix: ./etc etc.
./bin directory can be used to keep the subscriptions to bin directories of subscribed packages.
Then, putting symbolic links in various directories is bad idea. Instead, users could explicitly 'subscribe' to the directories. A special, user specific
Bad thing about RPM is that it uses a centralized DB for tracking dependencies, which can't be manupulated by hand. Instead, it could evolve to use 1. open format based on XML 2. Put the dependencies as part of independent directory tree of the package.
In most cases, it is sufficient that dependencies be evaluated dynamically. After all, sysads know what they are doing.
-vgk
* yes, that would be me :) Seriously, I install everything from source just to keep abreast with how everything works. mmmmm... breast.... :)
Sticking feathers up your butt does not make you a chicken - Tyler Durden
When I install software from source, I install it into its own directory in /opt, to keep everything together, and make it easy to uninstall.
/opt/foo/bin, /opt/bar/bin etc. into one's path and /opt/foo/man, /opt/bar/man etc. into the manpath to be able to run the programs. This is a right royal pain. So I use Stow to set up symlinks from /usr/local, pointing into the application's directory in /opt. Creating all those symlinks by hand (and deleting them all after deleting a piece of software) would be tedious and error-prone; having Stow do it for me saves time and effort.
The problem with that is that one needs to put
That's all. Nothing more complex than that. This isn't "package management" at all; it's just symlink management. But it's blooming useful symlink management.
-Stephen
Am I missing something here, or is this really just like having a zip file throw things around into directories? I admit not knowing about linux, and am doing little to change that.
Manipulate the moderator system! Mod someone as "overrated" today.
The article really should have tried to do a quick comparison with other package management systems, though I guess that is what /. is going to do anyway.
Congratulations! Now we are the Evil Empire
I don't need help managing my package, thank you very much.
Most (nearly all) of those install-sheild routines install the versions of dlls that the vendor has found it needs to work, and it's standard(sic) that winX applications install libraries into system areas.
That's just plain ugly, and why Win32 can be a very solid system iff you stay in the realm of well-engineered server applications, and So, so unstable when you turn lusers loose on it ('Ohh I really must have this latest whizbang screensaver or desktop doodad ....).
Imo this idiocy directly stems from the DOS/win16 programming(sic) history where there was no isolation at all from the hardware and many (most?) programss were coded to do all sorts of inane low-level calls to bios/hardware.
This just isn't allowed in Unix(linux,bsd ...) and it's as much a social/cultural issue as a technical one. Unix has 2 decades of enforcing the distinction between what's in the 'OS' hierarchy and what's in application space. Whether you want to discuss source-builds, defaulting to install in /usr/local/ or commercial installations which usually go into /opt, I've yet to see an application which would overwrite system libraries.
<RANT>
It's my observation that much of the shoddy coding that's found it's way into opensource in recent years is the direct result of windows coders bringing these bad habits into Linux.
The vast majority is being written without thought for portability and works only Linux and assuming the GNU toolchain (and often relying on version-specific features within same). Even within Linux, the difficulties associated with building code from source has taken many steps back into the past. Try building Gnome directly from sources.
A decade ago it was like this installing free / pd / gnu / oss software on the various proprietary Unixes. Sadly, after a period of big gains in portability, software builds are moving in the other direction. The complexity (often useless/needless imo) of much modern oss code has benefits, it also has drawbacks.
</RANT>
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
Not a very on point post, but I must admit... I get a kick outta this product, only 'cause I've been using "st0w" as a handle for about 10 years now... heheheh http://www.st0w.com And I would like to reiterate that I'm far better at managing software than rpm. I'm mildly offended...
I find that RPM only works well if you use nothing but RPMS. If I were to download the tarballed source of package X and build it for any number of reasons RPM would not notice the library or software or whatnot and I would be forced to use a --nodeps tag.
/usr, or /opt, or /home/username)
I dont think that a package manager should rely entirly on previous packages installed in one big database. I think package managers should try to do that PLUS there should be a tried and true (tried and true is that the proper phrase?) way to Anylize packages installed on a system.
I think that somewhay to tell which software is install on the system should be dynamic. There should be a file in which i point to all the places on my system where software is installed(ie.
Also another complaint I have with package managers is that I usually have no choice over where they get placed. When building from source I have the great option to append --prefix=... to configure (assuming the source complies with standards and such).
Even more offtopic: ever notice that software from large companies usually dosent conform to any kind of standard. Even if it is OSS ill see no autotools stuff. Ohh well probably just a GNU thing.
</End confusion>
This looks like packman (http://pack.sunsite.dk) only it's written in Perl instead of Python. Packman seems to have more features, like using a configuration fil (Does Stow have this?) also the packman.map which tells packman what to link and what not to link. Only problem is that packman was written for Python 1.5 and needs to be updated.
See the opt_depot page for one, and for links to another dozen or so packages that do the same sort of thing in varying ways.
Stow is really a rather GNU-come-lately entry to the Depot arena.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
I've been ranting about the stupidity of the FHS, and /,/usr,/usr/local directories for a long time, but all I get is vacant stares and comments along the lines that I am crazy for ever wanting to store applications in their *own* directories, as opposed to littering their content horizontally over the filesystem. But now this simple idea is illustrated in a developerworks article and all of a sudden it's "obvious". argh </vent>
It's 10 PM. Do you know if you're un-American?
By reviewing a better way to manage packages in Linux, IBM is destroying the value of Unix.
I have oft wondered about whether order not it would be good in the *NIX paradigm to have recursive paths. That is, you put /usr/local/bin in your path and then any files under that location would be in your path, eg /usr/local/bin/packageA/moduleB/bin, /usr/local/bin/packageX/bin, whatever (same for LD_LIBARY_PATH etc). Clearly you would not want this to be a universal rule since it is convenient to have "." in ones path some time but that would be recursively bad (same for some other directories as well probably). There is probably some good reason why this is a bad idea, butI have no idea what that is (sym links for example could be handled).
"The first thing to do when you find yourself in a hole is stop digging."
I'm sure we all remember that Eric Wright (RIP), when asked why he stows his package like that, said "for easy access, baby."
-Peter
That does not work, for a number of reasons. 1. This totally breaks Gnome. Gnome simply cannot be installed this way. 2. This can totally fuck up your shared libraries. There's a few other problems as well...
Sticking feathers up your butt does not make you a chicken - Tyler Durden
> 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."
>
>
Anything that requires Perl or any other such language is totally worthless. The advantages of rpm and apt is that they are pretty much self contained.
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!
Shameless Plug:
i s another alternative. It's beta now, but we're
spkgtool (http://www.scrudgeware.org/projects/Spkgtool/)
looking for testers and package maintainers.
...the amazing Emerge package management tool.
Amazing? Maybe if you've never seen it before. Maybe if you think the Free Unix world consists only of Linux. It's like saying "my new Sony television has this remote control feature that's amazing!" Yes it's amazing if you're never seen a remote control before. But it's still old hat. Yawn.
Now please excuse me, I need to upgrade a new set of ports that just arrived for my FreeBSD machine.
A Government Is a Body of People, Usually Notably Ungoverned
I was a build engineer for a large telecom company who had a commercial Windows product which used InstallShield. I wrote the installer for that product (twice). I've been using Linux since 1994 in various ways. I know InstallShield and I know Linux, and trust me, you don't want IS for Linux, no matter how much you think you do. People are better of sticking to whatever package management system comes with their distribution than pining away for something like InstallShield.
Having a single point of installation management is far superior (even with dependancy checking issues, like sometimes happens with RPM) than leaving it up to the software maintainers. Windows should have orginally shipped with such a centralized system IMO. Now they force software developers to jump through hoops (which cost money, incidentally) in order to get a sticker on their box saying their software was "Designed for Windows". Barring that "certification" a person can do whatever the hell they want in an installer, and your system can become an unorganized mess in very short order.
Even now on this Win2K machine I've got more than a dozen apps (most of which are commercially released) that aren't listed in the Add/Remove Programs applet. If I install something via RPM or apt, that can't happen. I just have to hope that one of those Win32 apps doesn't conflict with something else down the road, since there's no way to remove them programmatically. That's a critical flaw of Windows' installation setup, IMO. Just one that happens to come to mind, even. I could go on all day...
I admit not knowing about linux, and am doing little to change that.
Your parents must be terribly proud at having imbued in their progeny such an insatiable thirst for knowledge.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Groovy, I'll add a link to the collection on the opt_depot page.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
emerge "clue"
Stow looks like emerge for binaries, only with fewer options. :-)
It's the user's choice, as always. Emerge/portage will give the user an optimized system at the expense of compile time, looks like stow will have that same ease of use.
Looks cool. I hope that they come up with a good graphical frontend for it. Package management is one of those Really Important things when it comes to Linux on the desktop. We don't want end-users to have to deal with dependancies and all that.
You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
And has used it from the very beginning. So you could start recommending it right now ;-).
Checkinstall was initially developed in the time when makepkg had no command line options to answer the questions about symlinks and permissions, so Checkinstall uses by default a makepkg from Slackware 7.1 which was hacked to not ask those questions and instead assume specific answers to them. And it has been updated with the changes and patches introduced in Slackware 8.0 and 8.1 (i.e. the "slack-desc" file with handy ruler and all)
Aditinally, you can still use Slackware's native makepkg if you set the MAKEPKG variable in checkinstall.
environment :)
It's early here
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.
I agree, you don't want InstallShield. It sucks to program and sucks to use. Why don't more appliations install as follows:
/usr/local/bin and all other files in an application specific directory and set a shell variable to hold the application home directory location and have the main executable read the appliation's home shell varible to find everything.
Put the main executable in
There a limit on environment variables? Would having 934 such env vars slow down bash? I wouldn't even know.
The more I think about it, the more I think emerge and apt have the right idea.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.