Slashdot Mirror

← Back to Stories (view on slashdot.org)

Manage Packages Using Stow

Posted by michael on from the apt-get-still-rules dept.

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

5 of 213 comments (clear)

  1. Have you tried Gentoo's Emerge by salimfadhley · · Score: 5, Interesting

    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.

  2. What about dependencies? by jointm1k · · Score: 5, Interesting

    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.
  3. Why can't it be more like Windows? by esanbock · · Score: 5, Interesting

    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.

  4. stow is broken by Ender+Ryan · · Score: 5, Interesting
    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 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
  5. Re:Stow isn't Perfect, alas... by StormCrow · · Score: 5, Interesting

    A quote from http://cr.yp.to/slashpackage/finding.html

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