NixOS ( http://nixos.org/nixos/ ) is quite similar on the face of it, except that it does not make all the symlinks. Its package definition language is purely functional, too!
Though I really like the concept, I'm concerned by package availability (or a lack thereof). It's frustrating to have to take a big detour when developing to circumvent my linux's preferred way of package installation in order to get some newer version of a library.
On the other hand, I've almost just as many headaches with outdated libraries in the current Ubuntu repo (like anything Ruby, which is all for 1.9.1 and older, iirc).
I went with Arch for a while, but missed a lot of the conveniences of Ubuntu. I stick with Ubuntu since of all the distros I've used in 5 years of using Linux, it's given me the least friction when I just want to get stuff done.
I use PPAs (personal package archives) in Ubuntu to have a semi-rolling release. My browser, compiler and other select applications are updated daily but the underlying system is stable.
The idea of having packages installed in different directories is very convenient for development, you often need to install several versions of the same package and don't want to clutter /usr/local (or don't have root permissions)
Some months ago I have written a small tool that automates installing apps in separate directories and then symlink them to a directory in the path. It also supports disabling/reenabling/removing single packages (by removing the symlinks) and has a PIP fork to simplify installation of Python packages (also an "autobuild" for standard configure/make build systems)
It was written for development but actually it became my preferred system to install packages in Mac OSX, packaging systems (fink, macports...) are terrible there.
Stow installs packages in /usr/local, bpt in a directory specified by the user (for example under the home directory)
BPT uses the pair (name, version) as install directory, so it is possible to install several versions of the same package and switch between them.
The "boxes" (directories with packages) created with bpt are relocatable, so it is possible to prepare a box with all the applications and their dependencies and deploy it without needing root privileges.
It has first class support for python packages (through PIP) and "autobuild", which is similar to checkinstall.
I couldn't find these features anywhere else.
No, it doesn't. I've used stow heaps of times in my home directories on various university machines. The common case is for managing /usr/local, but you can ./configure --prefix=$HOME && make && make install prefix=$HOME/stow/foo-3.14 && cd $HOME/stow && stow foo-3.14 without trouble.
I'm using Arch now for two reasons. It is surprisingly easy to install and maintain. The documentation and wiki are the real reason behind this. I guess that's the surprise: docs beat guis, at least in linux distros.
Also I can keep a bleeding edge system up to date with out much trouble. I never could figure out how to do this with unbuntu.
I guess there is also a third reason. Arch seems to keep up with haskell developments very well.
I consider myself to be an underzealot. I wouldn't recommend it to anyone who doesn't already know how to get in and out of nano or vi.
My main motivation came from noticing the extensive support for haskell packages. I would have been happy to use a debian-based distro, but haskell seems to be too bleeding edge for distros like ubuntu to keep up.
The key point is that a package is stored entirely under /Programs/packagename - bash is stored under /Programs/Bash/3.0, and /bin/bash is just a symlink to /Programs/Bash/3.0/bin/bash.
When you want to uninstall bash, just use rm -rf /Programs/Bash/3.0.
They also have some tools which allow you to cleanly install programs from source in this manner, i.e. programs that are not included in the Gobolinux distribution. So regardless of whether Gobo packaged it, all programs are under package management (unlike yum/apt-get/etc).
Well apt has tools that help you install it through dpkg and manage it through apt, just not many use it.
What I am wondering is how they solve the dependency problem, like say something depends on bash and you remove bash with rm do you get any warnings or help or just a broken system? (This is more for when it is part of gobo and not installed from source).
Removing bash using rm would probably be a bad idea.
Although I think using the filesystem for this purpose is a good idea -- you get parallel-installed versions for free, and it's more reliable and transparent than what you get from rpm -- you're right that just deleting stuff willy nilly won't work. You still need to manage dependencies, and dependency graphs are not easy for humans to keep in our heads.
Liked your post, but a note that 'installing from source' doesn't correlate to lack of packaging. All OSS apps are installed from source, any anyone who knows autotools can package most things they're building in a few seconds on most Linux distros.
I compile stuff from source all the time, I just run rpmbuild -bb foo.spec instead of typing configure, make install manually.
Gobo looks a bit unmaintained, too :(