info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Stow


From: Eric Siegerman
Subject: Stow
Date: Fri, 25 Oct 2002 14:07:22 -0400
User-agent: Mutt/1.2.5i

On Fri, Oct 25, 2002 at 08:52:29AM -0700, Ray Tayek wrote:
> or suppose you download and install the latest version of your favorite 
> software and find that it just doesn't work. how about some way to 
> automagically roll back to a previous version?

Stow (http://www.gnu.org/software/stow/stow.html) is excellent
for this!  It's basically a package manager, but an extremely
lightweight one.

The gist is that you configure each package with
--prefix=/usr/local/stow/<package>.  My convention for the last
bit is package-version.  Thus, I configured CVS with:
        --prefix=/usr/local/stow/cvs-1.11.2
After installation, I ended up with:
        /usr/local/stow/cvs-1.11.2/
                bin/
                        cvs
                info/
                        cvs.info
                        cvs.info-1
                man/
                        man1/
                                cvs.1
                        man5/
                                ...

And so on.  Then Stow uses symlinks to create a unified view of
all those per-package directories, mimicking what you'd have got
by configuring them all with the default --prefix=/usr/local:
        /usr/local/bin/cvs -> ../stow/cvs-1.11.2/bin/cvs
        /usr/local/bin/stow -> ../stow/stow-1.3.3/bin/stow

But the files all live in the /usr/local/stow/<package>
directories; reverting a CVS upgrade would be as simple as:
        cd /usr/local/stow
        stow -D cvs-1.11.2
        stow cvs-1.11.1

I've been using Stow to manage /usr/local directories for several
years; it's become one of those little things I can't live
without.

Some hints:
  - The Stow manual goes on at length about how to fake out
    packages so that they think they're being built for
    /usr/local when they're really being installed into a stow
    directory, (this is so that they'll use stow's symlinks to
    find their auxiliary files, rather than looking directly in
    /usr/local/stow/<package>/share.

    Don't bother:
      - it can be a pain (though autoconf packages are generally
        pretty good about this)

      - IME, the behaviour they're telling you to jump through
        hoops to avoid, is usually what one wants!  E.g. speaking
        of autoconf, suppose one wants several versions of it
        installed (since it's broken backward compatibility once
        or twice).  Only one version can live in /usr/local.  So:
          - install them all into
            /usr/local/stow/autoconf-<version> directories
          - use stow to make the one you usually use be the
            default (i.e. accessible by a simple "autoconf"
            command)
          - explicitly invoke /usr/local/stow/autoconf-2.13/bin/autoconf
            for those projects that are still 2.13-based

        In this situation, you *need* that autoconf script to
        look in /usr/local/stow/autoconf-2.13 for all its
        auxiliary files; if it used whatever it found in
        /usr/local (e.g. the files for Autoconf 2.54), all hell
        would break loose.

  - Perl (up to 5.6.1 at least) "simplifies" its directory
    structure if it sees the string "perl" in its installation
    prefix.  For stow, this isn't what one wants.  So I use a
    prefix of "/usr/local/stow/perL-<version>".  The capital
    letter is enough to fool Perl's configurator, on UNIX anyway.
    "Perl-<version>" would also work, but "ls" would sort it up
    above the "a"s.

  - Don't be anal about it.  Some packages expect to be in their
    own subdirectories, rather than dispersed throughout
    /usr/local.  Humour them.  Be willing to let Apache go
    directly into /usr/local/apache as it prefers, rather than
    being stow-managed.  Or if you want multiple versions, put
    them in /usr/local/apache-<version> and make the (single)
    symlink by hand.  Likewise Java JREs and SDKs.

  - A frequent source of stow conflicts (it wants to install a
    symlink, but there's one already there) is
    /usr/local/info/dir, the dynamically built top-level
    directory to all the installed packages' texinfo
    documentation.  I don't have a good answer to this, but I
    don't find that feature very useful anyway; I always just say
    "info -f cvs" rather than bothering to look up the "CVS"
    entry in the top-level directory.

    So if I try to stow package "cvs-1.11.2" and it reports a
    conflict on info/dir, I just nuke cvs-1.11.2/info/dir, with
    extreme prejudice.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
The acronym for "the powers that be" differs by only one letter
from that for "the pointy-haired boss".




reply via email to

[Prev in Thread] Current Thread [Next in Thread]