Gobolinux - the filesystem is the package manager(gobolinux.org)
gobolinux.org
Gobolinux - the filesystem is the package manager
http://www.gobolinux.org/
7 comments
I like the idea of gobo (I used it for a little while) but the packages they had available just weren't doing it for me. I'm an arch guy, now :-)
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.
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.
Homebrew on OS X uses the same approach to install packages.
It works as long as the installed software doesn't have to modify system files (/etc).
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.
It's on pypi and doesn't require any installation, if you want to give it a try: http://pypi.python.org/pypi/bpt/
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.
It's on pypi and doesn't require any installation, if you want to give it a try: http://pypi.python.org/pypi/bpt/
Doesn't this do roughly the same thing as the Debian alternative system?
EDIT: I should have read your link first. It appears that your system allows for greater isolation and the ability to relocate different versions.
EDIT: I should have read your link first. It appears that your system allows for greater isolation and the ability to relocate different versions.
Yes, and also everything is contained in a single user directory, a "box". You can have multiple independent boxes.
Is this similar to Gnu Stow? Or does it do something significantly different?
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.
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.
> Stow installs packages in /usr/local
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.
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.
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 use Arch too, but I really don't get what this has to with GoboLinux...
No argument. I made the comment for the benefit of distro shoppers. They won't see it as off-topic even if it is.
I understand. I just fear that Arch users become another group of overzealous fanbois.
I have already seen the joke "How do you recognize an Arch Linux user? He will tell you" floating around on the web...
I have already seen the joke "How do you recognize an Arch Linux user? He will tell you" floating around on the web...
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.
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.
Reminds me a lot on NeXT and MacOSX. And I like it.
it's a neat idea but why use Gobo instead of other distros? The intro page doesn't really explain its advantages and benefits.
http://www.gobolinux.org/index.php?page=at_a_glance
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).
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).
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.
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.
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 :(