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

9 of 213 comments (clear)

  1. Stow isn't Perfect, alas... by dkf · · Score: 5, Informative

    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'!"
    1. Re:Stow isn't Perfect, alas... by Anonymous Coward · · Score: 5, Informative

      try encap. predates stow.

      http://encap.cso.uiuc.edu

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

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

    1. Re:Have you tried Gentoo's Emerge by Imran · · Score: 5, Informative

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

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

  5. 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
  6. remember this when deciding to try out stow by aagren · · Score: 5, Informative

    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:

    /usr/local/bin
    /usr/local/lib
    /usr/local/include
    etc

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

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

    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.