Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×


Sorry! There are no comments related to the filter you selected.

first post (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5492915)

at last

fp!! (-1, Offtopic)

Carl_Cne (253854) | more than 11 years ago | (#5492916)

First Public Post??


YOU FAIL IT! (624257) | more than 11 years ago | (#5493098)

You are nothing but a public embarassment, Carl the FAILURE!


Packing with SNOW ? OH! STOW!! (-1, Offtopic)

flsniper (655768) | more than 11 years ago | (#5492920)

For a second there I thought they were using SNOW as packing! Wouldn't that get VERY messy when it melted then I realized it was STOW!!! DUH! :::::::::Slaps himself upside the head!!:::::::::::

OH BOY -1 LAME (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5493030)

:::::::::Slaps himself upside the head!!:::::::::::

please do

Re:OH BOY -1 LAME (-1, Offtopic)

flsniper (655768) | more than 11 years ago | (#5493141)

:::::::::WHAM!!!:::::::: I did and now i feel soooooooo much better! Great suggestion thanks!

HAIL BUSH! (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5492921)

Raise the flag! The French have deserted us! No more decadent
European food! Be a patriot and support a true American home product!

Only the biggest American couch potatoes will become Idiot Fries(TM).
Fried in the finest propaganda oil made by CNN and FOX, Idiot
Fries(TM) come in three flavors:

- NRA ("Shoot your neighbor, it's called freedom!")
- KKK ("Color blind is not my problem!")
- WASP ("Superiority to the white trash!")

Idiot Fries(TM) are guaranteed to be free of UNO, ICJ, EC, AI, and
other non-patriotic substances.

"Only a true idiot will die for his country!" - George W. Bush

Linux? (-1)

Anonymous Coward | more than 11 years ago | (#5492924)

What about bzip2 or tar.gz?


Re:Linux? (1)

dkf (304284) | more than 11 years ago | (#5492943)

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...

Stow isn't Perfect, alas... (5, Informative)

dkf (304284) | more than 11 years ago | (#5492931)

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... :^/

Re:Stow isn't Perfect, alas... (5, Informative)

Anonymous Coward | more than 11 years ago | (#5492948)

try encap. predates stow.

Re:Stow isn't Perfect, alas... (4, Informative)

virtual_mps (62997) | more than 11 years ago | (#5492995)

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...

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".)

Re:Stow isn't Perfect, alas... (3, Insightful)

Uerige (206572) | more than 11 years ago | (#5493056)

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....
Why is this a problem with stow? You probably shouldn't hardcode paths into the binary, as that may lead to problems like this.

Re:Stow isn't Perfect, alas... (5, Interesting)

StormCrow (10254) | more than 11 years ago | (#5493340)

A quote from

``Software should never ever assume it knows where to get files from,'' someone once wrote. (He says I'm taking his quote out of context, so I won't identify him here.)
Here was my sarcastic response:

Yes, that's a very important principle!

Let's take, for example, csh, which uses /etc/csh.cshrc and /dev/log and /bin/sh and many other files. The reason that all those filenames are listed in /etc/csh.conf is so that they can be changed.

Now, some people want to move /etc/csh.conf itself. That's why csh looks for the /etc/csh.conf filename in a hashed /etc/registry.db file.

Of course, on some machines, we need to move /etc/registry.db. That's why the registry filename is listed in a COMPILEDFREGISTRY environment variable.

There's still the possibility of conflict with previous uses of the COMPILEDFREGISTRY variable. That's why the name of that variable is listed in /etc/fregistry_variable_name.txt.

You say you want to move /etc/fregistry_variable_name.txt? You fool! We have billions of programs that /etc/fregistry_variable_name.txt at the top of main(). Everything _else_ has to be configurable, obviously, but /etc/fregistry_variable_name.txt isn't going anywhere.

well... (4, Informative)

virtual_mps (62997) | more than 11 years ago | (#5492938)

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.

How long (1)

t0ny (590331) | more than 11 years ago | (#5493511)

how long is it going to take for something on linux to do what installshield does on windows?

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.

HTML newbies? (-1, Redundant)

42forty-two42 (532340) | more than 11 years ago | (#5492941)

[root@linuxbox app-1.4]# ./configure --prefix=/usr/local/stow/app-1.4 [root@linuxbox app-1.4]# make [root@linuxbox app-1.4]# make install

Looks like someone forgot their <br/> and <pre></pre> tags...

Re:HTML newbies? (1)

42forty-two42 (532340) | more than 11 years ago | (#5493131)

Redundant? I see no other posts pointing this out. What gives?

Unix Directory Structures (2, Interesting)

Boss, Pointy Haired (537010) | more than 11 years ago | (#5492955)

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.

Re:Unix Directory Structures (3, Insightful)

42forty-two42 (532340) | more than 11 years ago | (#5492982)

"My Documents"? Ever heard of /home/$username?

Re:Unix Directory Structures (0)

Anonymous Coward | more than 11 years ago | (#5493037)

"My Documents" is analoguous to the "Documents" subdir of the home directory that KDE+GNOME use. The windoze analogue of "/home/" is
"%systemroot%\Documents and Settings\"

Re:Unix Directory Structures (2, Informative)

cyb97 (520582) | more than 11 years ago | (#5493049)

Or as everybody else refers to it... ~

best of both worlds? (3, Funny)

Ender Ryan (79406) | more than 11 years ago | (#5493337)

How about `/home/$user/My Documents' ?

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 :)

Re:Unix Directory Structures (3, Interesting)

Sh0t (607838) | more than 11 years ago | (#5493023)

You have it backwards friends. It's not a crazy scheme it's a STANDARD and LOGICAL scheme. Programs installed to certain restrictive locations so you KNOW without trying to guess, where certain binaries go, where config files go and so on. It's a standardization and it works very well YOu just aren't used to it. IF you aren't installl from a system package you can put whatever you want, wherever you want, but to keep things orderly you should follow the scheme windows does the same things actually when you use installshield or msi, some files go to program files/program name, some go to /windows some go to a temp dir for settings, some entries go into the registry etc. I think the standard unix method is much tidyer overall, but it may be a bit confusing at first to those who are migrating.

Re:Unix Directory Structures (1)

mgv (198488) | more than 11 years ago | (#5493167)

I think the standard unix method is much tidyer overall, but it may be a bit confusing at first to those who are migrating.

Perhaps its just familarity, but the windows system is easier to me. Your stuff goes into the program files directory, the dlls go into windows directory, and your registry gets lots of hard to spot entries.

Its ugly but easy enough to understand.

I cant really understand the unix system, at least on red hat linux, because everone seems to use it differently.

Some things end up in /opt, some in /usr/bin, some in /usr/apps, and so on.

Personally, i would just put everything a program needs into one directory. Yes, even the replicated library code. You want to use in your program? Then copy that library also. Sure, it wastes hard drive space. But the alternative seems to be dependency hell.

Windows now has turned full circle, and the OS can track and substitute different dll versions called by different programs. Frankly, it would have been easier if we had never gone there in the first place. I'm not short of space on my hard drives, and few of us are these days, and the problems caused by incompatible versions of the same shared code just dont seem to justify the disk space savings.

Just define your core functions (kernel, x-windowing, or desktop environment). Everything on top of that gets its own copy in the same folder as the main code. You test once on the library that you want to code with, and that is that (hopefully).

New versions of the shared code don't change your program, because your program doen't use the newer versions unless you feel that it needs them and then you recode it at the developer level.

Just my 2c worth, probably too simple a solution to work of course.


Re:Unix Directory Structures (1)

IWannaBeAnAC (653701) | more than 11 years ago | (#5493374)

The problem with having multiple identical copies of shared objects lying around is that these multiple copies will end up loaded into memory, not just on disk. With a few applications running, it really does have a big effect on RAM. Also, if a library is updated (say to fix a security flaw) then you don't want to have to check every single app to see if it uses this library or not. And even then, if the application and library do not play nicely together, you will still have the problem that the library upgrade might break the app. In the case of a security fix, this is a serious problem. Some of these problems, of multiple copies of the library floating around, can (and are) fixed on *nix systems, using symlinks and hard links. But since you talk about using up hard disk space, I assume you are not talking about links? I don't think there is a magic solution to this. The Debian system perhaps works the best, with quite rigorous management of dependencies, but it is too labour-intensive to be used universally. It really comes down do discipline of library and application writers: library writers need to ensure that their lib is well specified, future releases are versioned properly, and minor releases don't break the interface. Application writers need to be careful to code against the interface, and not depend on some detail of the implementation. This is hard to do, but throwing multiple copies of libraries around is no fix either.

Re:Unix Directory Structures (1)

mgv (198488) | more than 11 years ago | (#5493507)

Also, if a library is updated (say to fix a security flaw) then you don't want to have to check every single app to see if it uses this library or not.

Thanks for your reply - it does explain why people are reluctant to do this.

I must admit that bug fixes would be an issue, although I don't see that searching your hard drive (or at least the program folders) for every copy of a library would be a problem if you had an updated version. It doesn't take that long to search a hard drive (esp. if indexed, but even if not).

The issue of taking up alot of ram is more of an issue. Of course, that only becomes a problem when the program is running, and even RAM isn't that expensive these days.

I'm ignorant of system architecture, but is there any reason why the code and data portions of shared libraries can't be managed separately? Ie., if you have invoked two identical programs, why not just issue memory twice for the data in the program, but keep one copy of the code? And if the versions are different, well, isnt' that the whole idea of what I am suggesting?

Ok, its probably still a silly idea, but just a thought?


Re:Unix Directory Structures (1)

xA40D (180522) | more than 11 years ago | (#5493101)

with something like "My Documents".

~username (tilde username) works for me.

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.

You could aways port the hier(7) manpage from a FreeBSD system - then insist that Linux (solaris, irix, etc., etc.) crowd follow the standard.

Re:Unix Directory Structures (1)

IamTheRealMike (537420) | more than 11 years ago | (#5493192)

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.

Agreed. The FHS is a laughably weak standard, with multiple potentially correct interpretations for parts of it.

Note that I don't have any real problem with names like usr, etc, opt - they are essentially meaningless except to programmers, which is how it should be, for users localised VFS systems which abstract and represent the data in the filestore are the way forward IMO.

Of course, that's assuming good old Hans Reiser doesn't tip the whole thing on its head with ReiserFS, right? ;)

Re:Unix Directory Structures (1)

Atzanteol (99067) | more than 11 years ago | (#5493261)


Great troll!

Stupid statements like the one about "My Documents" is sure to keep this flame burning.

Re:Unix Directory Structures (2, Interesting)

Permission Denied (551645) | more than 11 years ago | (#5493460)

You must be trolling.

Take any file on a modern Linux system. Any file at all. Explain to me its purpose and I'll tell you where you'll find it in the filesystem. A keyboard map? /usr/share. A subprogram to be executed by a program, not by the user? /usr/libexec.

Take any file on a modern Linux system and tell me its full path. I'll tell you what it does, and I'll probably be able to tell you what package it comes from. I can also tell you if you need it or if you can get rid of it. /usr/X11R6/lib/X11/rgb.txt? Rgb color database to define textual names for colors, from XFree86. /usr/local/share/automake/elisp-comp? Support file for automake to integrate with emacs, installed by user after system installation time, from GNU automake. /usr/local/lib/ Jpeg image library, installed after system installation time, from the JPEG group.

Take any file on a modern Windows system, and you won't be able to do anything with it. C:\winnt\keyacc32.exe? Does that come from MS or from a third party and what is it used for? C:\winnt\system32\getstart.gif? An image that says "Get started with Beta 2" in the Microsoft Arial font. Is this a remnant from a win2k beta and if so, why is still here in a production post-sp3 win2k pro system? Or does it come from some third party? Try figuring out what files are necessary on a Windows system and what's cruft. You certainly won't be able to get a Windows install to fit in less than ten megs because all these files are spread out and undocumented - however, you know it's possible to get a Windows image in only a few megs because Microsoft does it (miniwindows during Windows installation). Getting a FreeBSD install to fit in only a few megs is not a problem - just did it for a compact-flash-based system and it's not hard.

Anyway, this scheme that stow uses is very useful. Djb also has something like this in mind, but his way of doing it is not very elegant IMHO. I've been using something like stow for all my machines for the past three years or so, but it was just a 50-line shell script. Keep all software installed in /opt. Like /opt/emacs/emacs-21.1 with a symlink /opt/emacs/default which points to "current" version (that way, upgrades can be done with just changing a symlink, and downgrades are also just changing a symlink - you don't have to learn some tool's syntax, and, more importantly, the admin that replaces me won't have to learn some esoteric system because you can figure out my system in 30 seconds). All that my shell script does is make symlinks from the /opt/cvs/default/bin to /usr/local/bin, from /opt/python/default/lib to /usr/local/lib, etc. This way, when you run a poorly-written autoconf script, it will always find the requisite packages (because people always assume the required package is in /usr/local) and my users don't have to deal with $PATH. In addition, I can run this:

find /usr/local -type f -print
And this tells shows me all the stuff that I've written locally for the particular system (anything in /usr/local that's not a symlink must have been written by me).

Never run into any dependency problems, upgrades are "ln -s," uninstalls are "rm -rf."

Have you tried Gentoo's Emerge (5, Interesting)

salimfadhley (565599) | more than 11 years ago | (#5492957)

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.

Re:Have you tried Gentoo's Emerge (0)

Anonymous Coward | more than 11 years ago | (#5493019)

Is it possible to get Oracle to run on Gentoo? This is a serious question - I'll switch to Gentoo if the answer is yes.

Re:Have you tried Gentoo's Emerge (1)

TheVoice900 (467327) | more than 11 years ago | (#5493121)

A quick search through the Gentoo forums revealed this [] thread. It would appear the quick answer is "yes". Give it a read if you are still interested.

Re:Have you tried Gentoo's Emerge (5, Informative)

Imran (4369) | more than 11 years ago | (#5493105)

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.

stow and ebuilds aren't really operating in the same space.

rpm,deb,portage = full blown package managers, controlling everything under /usr. These can start with source (or pre-compiled binaries), and handle everything from installation to dependency-handling, etc (with varying degrees of efficiency).

stow = simple symlink manager, providing an easy way to maintain order within /usr/local, for those apps I compile and install manually (and, for whatever reason, don't want to repackage as an ebuild/rpm/whatever)

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:Have you tried Gentoo's Emerge (1)

TobiasSodergren (470677) | more than 11 years ago | (#5493203)

A nice and insightsful comment. I'd certainly mod you up if I had any points.

Re:Have you tried Gentoo's Emerge (2, Interesting)

nautical9 (469723) | more than 11 years ago | (#5493107)

I agree, Gentoo's portage is the best package management I've come across. Not only doe it make ANY package a one-line command that will automatically "download, untar, [patch], configure, make, make test, make install", but it uses system global optimizations for compiles, takes care of all dependencies, and places binaries, libraries, config files and startup scripts all in standard locations. And their "gentoo-sources" version of the kernel has over 70 high-performance patches it includes to the vanilla tree (but of course, you don't have to use them if you don't want to, but why not?)

It even has a great /etc/env system for managing environment variables (both bash and csh flavors), so if it needs to install binaries in a non-standard location, you "PATH" is automatically updated to include it.

I don't use Gentoo as a desktop platform, so I can't comment on its X/KDE/Gnome setups, but I'm sure they're just as complete and easy. And although Gentoo may be rather intimidating for a n00b initially, it does have excellent documentation and a great support community at their site [] .

Keeping a system up-to-date with the latest and greatest has never been this easy!

Re:Have you tried Gentoo's Emerge (1, Funny)

virtual_mps (62997) | more than 11 years ago | (#5493130)

Why did this article need a "use gentoo" comment?

Re:Have you tried Gentoo's Emerge (1)

Billly Gates (198444) | more than 11 years ago | (#5493231)

Agreed ports rock.

One of the reasons I prefer FreeBSD over Linux is because of better package managment. Gentoo is the only thing that comes close.

There are so many different distro's and versions of different distro's that is impossible to build an rpm that will not bring dependancy hell.

I wish there was a unix equilivant to installshield for windows. It would be great to have a self extracting executable with the dependancy .so or other programs already in it. It should be the job of the os or package installer and not the user to take care of this. The problem with an automatic dependancy installer like ports or portage is that it may automatically update some dependencies that use different scripts then the older versions you are using. This can cause problems not to mention the latest and greatest may have compatibilities issues. For example I hate redhat 8x because of the perl 5.8 packages. I use perl 5.6 and I can not downgrade without corrupting hundreds of packages that require 5.8.

What a pain.

Re:Have you tried Gentoo's Emerge (1)

sammy baby (14909) | more than 11 years ago | (#5493491)

I wish there was a unix equilivant to installshield for windows.

There is a Unix equivalent to InstallShield. It's called InstallShield [] .

Re:Have you tried Gentoo's Emerge (0)

Anonymous Coward | more than 11 years ago | (#5493376)

It WOULD be a great way to manage packages if I didn't receive so many errors trying to 'emerge sync' and md5 mismatches. I tried building Gentoo 1.4_rc3 just this week on my crapped out Linux box as I'm looking to switch to a more 'power user' distro than Mandrake, but after numerous failed attempts, I just threw Debian on it instead. So far, Debian is up and running, and apt-get, dselect, and other package management tools that Debian uses seem to be far more reliable than RPM's or the Gentoo Portage system.

Re:Have you tried Gentoo's Emerge (3, Insightful)

Ed Avis (5917) | more than 11 years ago | (#5493448)

I don't understand why many people seem to assume 'tar good, rpm/dpkg bad'. For example, the article says:
Although some Linux flavors such as Red Hat and Debian come with their own package management utilities (rpm and apt-get, respectively) that are as efficient as Stow, they work only on specific packaging formats (.rpm and .deb, respectively). When it comes to managing applications simply packaged in .tar files, Stow is the best bet.

Why is a tar file any more 'simple' than an RPM or Debian package? If you are just storing a bunch of files, then yes. But what about metadata? That is, the information on dependencies (what libraries the package needs), where to get the source code, who the packager was, which version of the software these files represent, whether this packge conflicts with any other packages that might be installed, and all the other things that a decent package manager keeps track of automatically so you don't have to check them by hand, or get nasty surprises when you've installed a package and only later find a necessary library is the wrong version.

If you use tar files then you'd need to have an extra metadata file inside storing this information: then you need to decide a format for that file and write a tool to parse it. And you've then reinvented rpm or dpkg, only with the spurious 'improvement' that people on other systems can unpack the archive if they have tar installed. As if anyone running a different system would need to unpack someone else's binary packages.

Perhaps you could argue it would have been better for rpm to be based around tar.gz format, with the package details stored in the tarball as a script of some kind. But then it would become much slower to query a large directory of packages. Maybe that is important, maybe not. Also you have digital signatures to worry about, it's not clear how to do those with a tar archive (unless you have one tarball containing another tarball plus its PGP signature). Perhaps things could have been done differently, but the mere fact that the rpm and dpkg developers chose to make their own format rather than use tar is not an excuse for committing much more serious wheel-reinvention in making a kewl Yet Another packaging format.

I'm not meaning to knock Gentoo here, that distribution really does do something new (building everything from source), and they perhaps had good reason to make a new packaging format. (Although it might have been worthwhile to investigate whether building from source could fit in with rpm or Debian source packages.) And Slackware has used tgz packages since the beginning, and doesn't seem that bothered about automatically tracking dependencies.

But for most uses, I just don't see why 'simple packaging with tar' is particularly simple in the long run or much of an advantage. It sounds like those Freshmeat projects which say 'this is yet another MP3 player but it has the advantage that it doesn't use GTK or Qt but implements its own user interface code instead'.

What about dependencies? (5, Interesting)

jointm1k (591234) | more than 11 years ago | (#5492958)

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.

Re:What about dependencies? (2, Informative)

virtual_mps (62997) | more than 11 years ago | (#5493022)

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.

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.)

Maybe they should do some more homework and take a look at Gentoo's Portagepackaging system.

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 them? (0, Offtopic)

Ender Ryan (79406) | more than 11 years ago | (#5493412)

If you're the type who masochistically* installs everything from source, you can probably handle dependencies yourself.

* yes, that would be me :) Seriously, I install everything from source just to keep abreast with how everything works. mmmmm... breast.... :)

How does Stow handle dependencies? (2, Interesting)

Max Romantschuk (132276) | more than 11 years ago | (#5492959)

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?

Re:How does Stow handle dependencies? (1)

Dr. Manhattan (29720) | more than 11 years ago | (#5493050)

Well, there's Encap [] , which handles dependencies but currently only among other Encap packages. It's similar in putting files in one directory and using symlinks.

It doesn't (2, Informative)

ggeens (53767) | more than 11 years ago | (#5493068)

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? (4, Informative)

Anonymous Coward | more than 11 years ago | (#5493069)

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:

ls -lL > /dev/null 2> /tmp/T
rm `sed s/:.*$//g`

Wow? (4, Interesting)

j1mmy (43634) | more than 11 years ago | (#5492970)

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.

Re:Wow? (1)

virtual_mps (62997) | more than 11 years ago | (#5493045)

Think of a typical /usr/local on a multiuser system. These are not typically managed by the native package management system, and have a whole mess of binaries dropped into /usr/local/bin. If you're the unfortunate sysadmin who has to figure out what package a particular binary is from, you're in for a lot of guesswork. With stow all the binaries are symlinks to descriptive package directories, so it's easy to know what files are related. If you want to get rid of something you don't have to go on a research expedition. If you do an upgrade you can simply unlink the old version and link in the new version, then quickly put it back if something breaks. This is good.

The other alternative is to build all your local compiles as rpm's (or sysv packages or whatever), but that's usually more work than just "./configure --prefix=/usr/local/stow/foo-1.2; make; make install" Getting your junior sysadmin to build things into stow repositories is usually easier than trying to get them to handcraft solaris packages for every little program somebody wants installed.

Why can't it be more like Windows? (5, Interesting)

esanbock (513790) | more than 11 years ago | (#5493006)

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 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.

Re:Why can't it be more like Windows? (0)

dirbinhas (623896) | more than 11 years ago | (#5493054)

You don't have to edit config files in Windows, because there isn't much to configure with Windows -- another reason to use Linux. I think what you are looking for is Gentoo. It's a bear to install the OS, but installing packages is a no brainer.

Re:Why can't it be more like Windows? (1)

termos (634980) | more than 11 years ago | (#5493143)

Fuck sake, I wrote a really long reply and then my Mozilla crashed! Anyway:

If Linux and other GNU systems should have something like that it would have to be some kind of standard for all software. Like most Windows programs have the Vice installer or whatever it is called.
GNU systems has something similar. It is called autoconf and automake which work almost the same way (just that for example Linux don't have a registry), it places files in the correct locations.
On the side you also have APT, Emerge and RPM which does the same thing, but they don't have a graphical front-end (at least not by default, could find some for at least Apt and RPM on I believe). To just change the standard most GNU systems already are using it would be a huge step both for the user and the developer IMO.

Re:Why can't it be more like Windows? (1)

pubjames (468013) | more than 11 years ago | (#5493158)

In windows, I double-click setup.exe, a GUI pops up, I pick the destination and off it goes.

Absolutely. This type of thing is essential for Linux if it is going to gain widespread desktop use.

I know it's complicated. But it just has to be made simpler for the end user, no excuses.

Like everything in the OSS world, there are loads of different projects taking different approaches. Whilst this isn't a bad thing, eventually a standard needs to emerge, and the sooner the better. I think more people should help out with Autopackage [] , which seems to be taking the right approach.

Re:Why can't it be more like Windows? (4, Insightful)

IamTheRealMike (537420) | more than 11 years ago | (#5493246)

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?

A few reasons. Firstly, these programs are tremendously complex under the hood. Almost all generic ones (even light ones like NSIS) include their own scripting language. InstallShield 6 and up has used DCOM to provide remote procedure calls between the install script and the engine (ikernel.exe if you've ever wondered what that is). They do a lot of messing around under the hood in order to make things just work.

Even then, they are too primitive for Linux. For instance, they have only basic concepts of dependancies. The lack of proper dependancy management almost brought Windows to its knees in the mid-nineties. Simply packaging every dependancy inside one self-extracting archive is simply not possible on Linux in any scalable fashion, so we have to build dependancy resolvers like apt. Windows installers tend to be GUI only. And so on.

Now, systems like apt are pretty cool. When they work, they work really well. The problem is, that they tend to be built by distro projects, and then they are relatively tied to that distro. Apt as used on Debian for instance, is not the same as apt4rpm. URPMI is Mandrake, and emerge is basically tied to Gentoo, though I'm sure it could be generalised.

So, the real solution is not to build Windows style setup.exe files. The real solution is to make something like apt, but that can be easily used by everybody, so you rarely if ever come across software that doesn't use it.

There are two approaches to solving that problem. We're trying both at once. The first is to invent a new system, independant of the existing ones. See my sig. The second is to try and standardise key interfaces in a standards body, so that apt/urpmi/emerge and others can interoperate, and so you can plug distro-neutral packages into that framework. See here [] . Note - most of the activity so far related to that group has been off-list, hopefully there will be action starting in a few days.

Re:Why can't it be more like Windows? (2, Interesting)

Darth Yoshi (91228) | more than 11 years ago | (#5493265)

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?

Didn't Loki [] write a graphical installer for Linux? I can't access the Loki site from work to check because it's blocked by websense (ha).

because that would be bad (4, Insightful)

g4dget (579145) | more than 11 years ago | (#5493283)

In windows, I double-click setup.exe, a GUI pops up, I pick the destination and off it goes.

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.

Re:Why can't it be more like Windows? (1)

Billly Gates (198444) | more than 11 years ago | (#5493319)

My guess is some people do not want to download huge files. If you want to upgrade the latest kdevelop a whole QT, and KDE would come with that download. It would be well over a 100 megs this way.

While this was important in 1995 when everyone still used 14.4's on the internet and only had 50-70 packages at the most, its extremely inefficiant today with linux distros with 3k+ packages.

Also in Windows only runtime dlls that are dependencies are updated in a setup.exe program and not whole software packages. For example in a typical Windows setup.exe program usually a vb runtime .dll is included, an updated mfc.dll and maybe some activex.dll's for an outdated system still using ole 2.0 . It does not install Visual Basic, all of the mfc classes and a new win32api, a Windows based sdk for activex. Only the required dlls to run it.

For example the win32 version of gimp has a 6 meg install .exe and an 8 meg .exe. Because I did not want to lool for gtk++ for Windows I just downloaded the 8 meg version.

Same should be true of linux. 2 options one lite for massochists and one bloated for everyone else.

Re:Why can't it be more like Windows? (1)

horza (87255) | more than 11 years ago | (#5493375)

Most of the apps I install under Linux these days are far simpler to do than under Windows. As I use Gentoo, I just type "emerge {name}" and everything is done for me automatically. If I want to use the original sources, I normally type ./configure && make && make install and everything just works. You can type ./configure on its own to see a list of options but the default normally works for me.


Rather Amiga assigns (1, Informative)

Anonymous Coward | more than 11 years ago | (#5493008)

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.

Try Using Gentoo Instead (1)

chayim (653306) | more than 11 years ago | (#5493013)

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.

Re:Try Using Gentoo Instead (3, Insightful)

Skater (41976) | more than 11 years ago | (#5493189)

So, I took my Chevy Cavalier to the dealer this morning to get brake work done. He strongly recommended that instead of fixing the Cavalier, I should convert to Gentoo. It apparently solves all of my problems.

Sorry, but I get tired of people always saying this type of thing about ...well, anything. Examples:

Q: "I need help with my sendmail configuration." A: "Use postfix/qmail/etc."

Q: "How do I get <some device> working under Linux?" A: "Use FreeBSD."

Q: "Take a look at this package management system." A: "Switch your distribution!"

All of these have better, usable answers that actually answer the question.

I don't mean to flame or troll, but responses like this are counterproductive and annoying.


Stow - slow (1, Funny)

Lothar (9453) | more than 11 years ago | (#5493014)

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.

Why not use M$ *.cab files??? (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5493016)

:) ...ah fuck all your Desktop-Distro-and-Blah topics...

I always used to "install" straight from CVS...

The goal of my life is ... (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5493020)

... to post a FP on Slashdot!!
One day, I'll succeed it!

PLEASE, what should I do with my life ??!

Re:The goal of my life is ... (0)

Anonymous Coward | more than 11 years ago | (#5493044)

PLEASE, what should I do with my life ??!

End it?

It's all in the name (1, Funny)

Martijn Ras (658497) | more than 11 years ago | (#5493024)

Simply Throw Out Window ...

ugh! looks proprietary! =( (1, Insightful)

Dri (16940) | more than 11 years ago | (#5493032)

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"

Re:ugh! looks proprietary! =( (0)

Dri (16940) | more than 11 years ago | (#5493083)

.. i've now read the article and came to the conclusion that I've made a complete fool out of myself.

Re:ugh! looks proprietary! =( (1)

IXI (586504) | more than 11 years ago | (#5493326)

Why is that when companies releases something,[...]

Not only that, the software comes straight from the GNU FTP server. It has been around for years, but not for replacing package management systems and not "for Linux". It is designed to manage unpackaed software in locations like /usr/local.

So now you can stop the hype and calling it lame because it's a generic GNU tool and not from IBM.

The truth... (0, Funny)

Anonymous Coward | more than 11 years ago | (#5493033)

There is only one true way: CVS

Everything else is as good as CAB files :)

What about autopackage? (1, Informative)

Anonymous Coward | more than 11 years ago | (#5493036)

I have more faith in GNU Autopackage [] myself.

stow is broken (5, Interesting)

Ender Ryan (79406) | more than 11 years ago | (#5493038)

Don't attempt to use stow for things such as Gnome or KDE. If you attempt this, things will get horribly broken for a number of reasons.

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 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.

Stow and problems with "make install" (4, Interesting)

Anonymous Coward | more than 11 years ago | (#5493043)

As you may or may not know, Stow relies on "make install". And as you may or may no know, "make install" has many weaknesses, maintainability and readability being two of its most glaring problems.

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).

Re:Stow and problems with "make install" (2, Insightful)

IamTheRealMike (537420) | more than 11 years ago | (#5493428)

A better solution would be to replace automake with a totally new build system. We've been hacking around the deficiences of make for years, and the time when compatability with lame commercial unices form of make was an issue is long gone.

Something like SCONs [] perhaps, although I'm not sure python is the best language for this. Although it's possible, easy even, to write really ugly bash, it's a very good language for filing system manipulations, which is a large part of build management. There was another build system based on bash that was a LOT easier than autotools, but I can't remember what it was called! :(

Encap is better (4, Informative)

tskirvin (125859) | more than 11 years ago | (#5493053)

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.

Re:Encap is better (0)

Anonymous Coward | more than 11 years ago | (#5493504)

I tried encap. Still feels like a kludge compared to Amiga assigns or even RiscOS/MacOSX/NextSTEP AppDirs.

remember this when deciding to try out stow (5, Informative)

aagren (25051) | more than 11 years ago | (#5493078)

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..)

But remember one thing. If you are starting with a new stow system in f.x. /usr/local, then be sure to make the directory structure:


if it doesn't exit before stowing anything. Otherwise the following will happen. let's asume that you have the software package in: /usr/local/packages/app-1.4

with it's own strucure like: /usr/local/packages/app-1.4/bin /usr/local/packages/app-1.4/lib

stow'ing this packages without the /usr/local-structure will result in:

ls -l /usr/local

bin -> packages/app-1.4/bin
lib -> packages/app-1.4/lib

Then the nect package (let's call it app2-1.5) you will be stow'ing to /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.

Re:remember this when deciding to try out stow (3, Informative)

virtual_mps (62997) | more than 11 years ago | (#5493145)

Then the nect package (let's call it app2-1.5) you will be stow'ing to /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.

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 /usr/local/bin.

Re:remember this when deciding to try out stow (1)

aagren (25051) | more than 11 years ago | (#5493215)

my observations above might only happen with an older version of stow. I've haven't tried the scenario lately. If that's a fact I apalogize for misguiding you :)

ROCK Linux (1)

blindcoder (606653) | more than 11 years ago | (#5493094)

kinda sounds like ROCK [] 's .gem files.
.gem is really only a tar.bz2 with that tad bit of extra information needed to overcome the shortcomings of tar, which is:
You want to extract ONE single file from a 100 MB tar-file and tar reads the whole file to extract that single file.

Package Management? (2, Interesting)

rampant mac (561036) | more than 11 years ago | (#5493110)

I know this will probably come off as flamebait, but what is Linux doing to make program installation / de-installation easier?

Sure, package management is wonderful, but it's not something I would recommend for my parents to use. They have enough trouble setting the time on their VCR, and my mother still can't grasp the concept of tabbed browsing after I set her up with Mozilla.

Will Linux ever mature to the point where applications are bundled like they are in OS X... Where a new user can install a program by dragging one icon to install a program, and then drag that same icon to the trash to uninstall it?

How could this be implemented?

Re:Package Management? (1)

IamTheRealMike (537420) | more than 11 years ago | (#5493408)

Will Linux ever mature to the point where applications are bundled like they are in OS X... Where a new user can install a program by dragging one icon to install a program, and then drag that same icon to the trash to uninstall it?

Forget appfolders, at least for now. Implementing them properly on Linux (ie with dependancies, system integration etc) is just too hard for the short to medium term. MacOS gets around these problems by hiding from them or because being a proprietary OS they aren't relevant - not really a route Linux should take.

As for drag and drop packages, now that is certainly possible. The UI for software installation need not be directly related to how it's implemented. How does this sound?

You browse to a web page in say Moz/Ephy/Konqueror/whatever. These pages are XHTML - inside them is a small set of namespaced XML elements which interfaces with X Drag and Drop. It basically places an icon of arbitrary size (think SVG) with a caption, just like in a file manager, into a web page.

This icon represents an object. It wouldn't have to be a package, but let's focus on that use case for the moment. The user goes to a web page, reads about this cool new software. They see the icon. They drag the icon out of the webpage (leaving an empty container or something behind) and onto a panel. A panel, in case you're not aware, is a collection of app launchers, applets, start menus, task lists and so on. KDE and GNOME provide them, see here for a couple [] .

The user drags the icon onto one of the panels. The icons budge over to make room (think dock here), and the user drops the icon in. It immediately fades to grayscale, and a small rotating "busy" animation" [] appears in one corner.

So, the package starts downloading in the background, as the system resolves the package and its dependancies to the nearest mirror servers, and locatest the right CPU architecture for binaries and so on.

Meanwhile, the user gets on with their work. On a dialup connection (ie most connections) downloading software is slow, so people want to just get on with playing their games or whatever. Now the packages download and install in the background, automatically. If there is user interaction, a small throbbing RHN-style system tray icon would appear, and when the user clicked it, the interactions would take place, and then the window would disappear and the install continues. Most packages wouldn't have interactions by the way.

Clicking the icon while grayscale gives download status, speed, ETA and so on.

Finally, when it's done, the icon goes back to being coloured, and clicking on it launches the app.

OK, so what if you drag it to the desktop you say? Well, the same thing basically, the package is downloaded to your desktop (any dependancies get put into a cache) and is grayed out until done. If you click it, the installation proceeds as normal, and the package turns into a launcher.

Note that we now use a vFolder based menu system. With a bit of extra work, that means app launchers could be reference counted, and that means that uninstalling becomes a matter of dragging the launcher to the trash can. If other users have launchers for that app on the system, the app stays installed until the refcount drops to zero, at which point it could automatically garbage collected when the system is idle.

Having a network based system like that let's you do a lot of cool stuff. For instance, if you encounter a new file, the mime-type sniffers will pick up what kind of file it is (even for compound stuff like MS Office docs) and could query the network for packages that can view or edit that filetype. All this becomes possible, when the current packaging system becomes unbroken, which is what we're currently working on.

Why Hasn't Stow Caught On? (4, Interesting)

4of12 (97621) | more than 11 years ago | (#5493111)

I remember seeing mention of it a couple of years ago on the GNU site.

Was it just that it was not completely developed, or are there other issues that are inhibiting broadscale adoption of stow?

I'm not deliberately trolling, I just wanted to know.

A few random things I do know are:

  • how to go from .tar.gz through configure;make;make install
  • that Red Hat's rpm [] package manager has a 400 page manual and believe the learning curve looks like Mt Everest
  • Debian folks swear by apt-get []
  • writing autoconf [] macros [] makes me weary
  • gar [] (of Linux BBC fame) looked like an interesting superpackager

No "package-manager" (4, Interesting)

Eivind (15695) | more than 11 years ago | (#5493115)

Stow is no replacement for a package-manager. It doesn't even *attempt* to do 99% of what a package manager is for. RPM and deb do all of the following, (sometimes trough frontends like urpmi and apt-get) stow doesn't do any of them:
  • Solve dependencies automatically.
  • automate configuration and building of packages if you prefer to build yourself. (with stow, building is a manual task)
  • Warn you if two packages conflict with eachothers.
  • Verify integrity of an installed package.
  • Handle updates to installed packages.
Infact, all stow does is let you yourself manually deal with all of the above, only you're supposed to run configure with something like --prefix=/usr/local/stow/mypackage and only when you are finished with all this will stow handle the amazing task of making apropriate symlinks from the application-directory to some directory on your path, a task that would take all of 10 seconds to do by yourself.

Pointless utility made by someone who apparently doesn't even understand which job they're trying to do.

The article is also full of typical misunderstandings like:

On Linux systems, most applications are required to be installed in some specific directory (which is usually /usr/local/), to run and function properly; the requirement comes either from Linux or from the application itself.

There exists *no* requirement "from Linux" that any application reside in any particular directory, except the default kernel excpects /sbin/init to exist.

I'm also not aware of a single package that requires living in /usr/local in order to function.

Re:No "package-manager" (1)

IamTheRealMike (537420) | more than 11 years ago | (#5493454)

There exists *no* requirement "from Linux" that any application reside in any particular directory, except the default kernel excpects /sbin/init to exist. I'm also not aware of a single package that requires living in /usr/local in order to function.

I originally thought he was referring to the fact that by default apps are configured to /usr/local, and unfortunately most apps written for Linux are not relocatable - they must be installed to the same prefix they were configured to. That's a problem we're currently working on in autopackage. But then I realised that this utility isn't meant for binaries, and you always choose the prefix yourself.

So I don't know what to think, except maybe the author was slightly confused or used poor wording.

Hey, I remember stow! (1)

Sciamachy (198192) | more than 11 years ago | (#5493117)

Didn't "stow" use to be the command to compile SoftwareAG's Natural [] applications? I learned mine on a VAX so I dunno if it's the same in *nix.

better filesystem layout (5, Insightful)

Erpo (237853) | more than 11 years ago | (#5493120)

If I understand the explanation correctly, stow gives the user the ability to keep all of an application's files together under one directory (as opposed to sprayed out across the system) while creating symlinks to simulate the files' presence where they "should" be.

<rant mode> IMHO, this attempt at package management only goes halfway. The basic idea driving it is that while programs may need to put files into preexisting function-categorized system directories (/usr/local/bin for executables, /usr/local/etc for configuration files, etc...), it's much more convenient to have all of the files under one program-specific directory so that important files can easily be located and manipulated.

What this says to me is that *puts on asbestos suit* the windows model for software management and installation is highly superior to the gnu/linux model in many respects. Don't get me wrong. I'm not a fan of windows, and while the actual _implementation_ of that model on windows leaves much to be desired (e.g. uninstalls are not always complete), it's a great model.

"Things you add to the system" are divided into two categories: core system stuff (e.g. libraries) and application programs. If it's core system stuff, it gets dumped into a system directory where programs can actually find it. No need for /etc/ If it's an application program, it gets its own directory and everything goes inside that. No spraying messy files all over the system and not providing an easy way to remove them (again, according to the model, not the windows implementation), no hunting down configuration files, and no guessing which application a file "belongs" to.

Maybe there's some really important piece of functionality that the *nix model provides and the windows model doesn't, but I certainly don't see it. Perhaps someone with more experience could tell me why we shouldn't work out a better filesystem hierarchy and try to convince gnu/linux distro maintainers to adopt it? Couldn't we do better?

</rant mode>

Re:better filesystem layout (1)

IamTheRealMike (537420) | more than 11 years ago | (#5493476)

"Things you add to the system" are divided into two categories: core system stuff (e.g. libraries) and application programs.

That works OK when there is as clear divide between system stuff and everything else. In the case of Windows or MacOS, if a component is made by Microsoft or Apple, then it's probably system stuff. Otherwise, it's everything else.

But Linux doesn't work like that. If I install RhythmBox, it might want to pull in the GStreamer multimedia framework as a dependancy. GStreamer doesn't come with Redhat 8.0 (though it does in 8.1). Is it system stuff or not?

What about GTK? It is only one of several widget toolkits in use. Is it "core" or not?

Well, really when every component can be potentially upgraded externally, the line between system and application becomes blurred, so you have to deal with them all equally - hence package management.

Re:better filesystem layout (0)

Anonymous Coward | more than 11 years ago | (#5493495)

Perhaps you might like the ROX [] approach, with its application directories. From a user perspective it is quite simple, just drag in a new app.

The main barrier to this is adoption by the publishers and packagers. Also remember, the simple interface like this starts to break down if the system is multi-user, too.

Excuse me? (3, Insightful)

arvindn (542080) | more than 11 years ago | (#5493160)

Could somebody please enlighten me? I don't get the point at all.
... 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
"A standard tar file" is just a bunch of files. The reason rpm and other packaging formats are used is to do dependency tracking and management. There is no way you can figure out the dependencies from just the tar file. So comparing stow with rpm is like comparing apples and oranges. Stow is not an alternative to rpm. (Of course I agree that if we had a single universal packaging format it would be great. But the answer is not to throw all the features overboard.)
... and keep application binaries logically arranged for easy access.
Wtf? What do you mean, access a binary? When is the last time you did "vim /bin/ls"? The only thing you do with binaries is to execute them, and putting them in /bin/ or /usr/bin/ etc. is perfectly adequate.
gives users the freedom to store or install the software package at any desired location
Excuse me, but "configure --prefix=dir" already does that?
Imagine installing an application that accidentally overwrites a file belonging to another application, and then you have to replace the file.
Has anyone ever encountered this? It seems somewhat contrived to me.
Or imagine, before uninstalling and deleting an application, trying to determine which files belong to that application.
Any half-decent package manager allows you to list all the files belonging to an application.

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.

errr (p.s. gentoo fanboys look here.) (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5493169)

have not used stow, but on my trusty slack box i use checkinstall, which after youve done configure and make, instead of doing makeinstall you run checkinstall, which runs make install. or you can run checkinstall installcommand. anyway, checkinstall installs, and then creats a package, (choose from slackware, deian or rpm), and installs, you can then uninstall package as needed.

now for gentoo..idiots...

gentoo only has one thing going for it, emerge, and whether that is any better than apt get, or the slack way, is dependant on user opinion. as for the compile everything yourself stage, how stupd, there is no speed improovment from compiling fileutils, or vi etc, you should only compile kerne, and large things like snort, mysql etc

Another way (2, Interesting)

tallniel (534954) | more than 11 years ago | (#5493185)

I think more people should take a look at tclkit ( and the concept of starkits ( 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.

See also Linux Mag France (2, Informative) (583400) | more than 11 years ago | (#5493187)

For french guys, there is a Stow tutorial in GNU Linux Magazine France of this month ( The article is not available online.

Here is the author web site :
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 :
See also XStow :


packaging (1)

Phacka (144710) | more than 11 years ago | (#5493200)

standard slackware 'installpkg' with 'checkinstall' does the job quite good, besides 'make prefix=/your/path install' breaks a lot of apps

Use checkinstall instead (4, Informative)

wct (45593) | more than 11 years ago | (#5493359)

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.

Dependencies should use open format ... (3, Interesting)

vinod (2092) | more than 11 years ago | (#5493373)

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.

Then, putting symbolic links in various directories is bad idea. Instead, users could explicitly 'subscribe' to the directories. A special, user specific ./bin directory can be used to keep the subscriptions to bin directories of subscribed packages.

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.


Stow is useful for a specific, simple task (1)

Stephen Williams (23750) | more than 11 years ago | (#5493486)

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.

The problem with that is that one needs to put /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.

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.


SEPP ideal package management (2, Informative)

schweikert (21009) | more than 11 years ago | (#5493513)

SEPP [] is a package management system that allows to separate packages in directories like Stow and similar, but in addition:
  • solves the distribution problem by allowing to mount packages with NFS and using the automounter to make the applications available under a standard path (/usr/pack/PACKAGE)
  • provides for each application a wrapper script that takes care of all the necessary environment setup so that users don't need to edit their bashrc
  • supports installation of multiple versions of the same application by installing version-tagged binaries in addition to the normal binaries. I can for example run mozilla-1.1 or just mozilla, in which case I get the "default" version. This is very important for example for a Ph.D. student that wants to finish his thesis with Matlab 5.3.
  • automatic generation of web documentation (have a look here [] )
  • usage logging with syslog
  • dependencies
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>