[Help-stow] managing multiple versions of software tools

[David T-G]

Hi, all --

I've just discovered stow and I think it might help us manage our
software development environment.  I need more information, though.
I'm afraid this will be a bit long because I go into some background;
I hope it doesn't put you off (it won't take more than a minute or two
to read it, really!), and feel free to trim without mercy in your replies.

I tried to go to the savannah page to look at the mailing lists and, in
particular, check out the archives, but I got an error.  Please excuse
the perhaps-oft-asked questions herein!  Please also copy me on any
replies as I try to get myself subscribed (hey, I wonder if this will
even go through since I'm not yet subscribed...).

I'm certain that others have not only attempted but entirely overthrown
this challenge before, but the trick is finding their methods :-)
We're a software development shop and have the need to "capture" and
document our build environment -- this version of the OS and those patches
(that part is old hat to me and mostly requires documentation 'cuz we'd
reinstall on a target machine rather than running virtual machines),
this rev of the compiler, that version of perl, and whatnot -- so that,
three years from now when we have to fix a bug in some old code, we can
dust this off, perhaps unpacking from tape or perhaps rebuilding from kept
sources, and ensure that we have the same environment for the same code.
In the meantime, we want to forge ahead and use fairly current versions
of these tools for any new projects.  Occasionally thrown in are special
versions, like a perl that has had some tweaks applied or knows about
a special module.

The initial approach was to get the GNU software toolset CDs (as well
as some other sources, like perl) and build 'em under a directory named
for the set; currently, everyone has .../gnu_13/$os/$chip/bin in his
path (yes, from early in '99; this has been a problem for a while and I
fear that someone has casually upgraded gcc or perl without telling!).
That's one approach, and we could continue that by gathering the latest
and greatest every quarter and adding a buttload of disk space, plus
any entire build trees needed by a single project just because they need
one thing different (like that tweaked perl).  The person who maintanied
that is gone and didn't leave behind any documentation, so we have the
opportunity to start fresh.  I, the temporary contractor, have only a
couple of months to get something placed, polished, and documented so
that it not only works but can be maintained by the permanent staff here.

On the first read, stow looks great (well, for my purposes; it's clear
that it's great anyway!).  After deeper examination, though, I'm not sure
it will do what we need.  It looks like stow lets you cleanly manage a
current version of a bunch of tools all in one easy-to-$PATH place, which
is great for a site doing upgrades and going forward but not so hot for a
site that wants to capture an environment for posterity.  Do you agree?

One approach is the periodic monolithic build described above, but that's
expensive (well, disk space is cheap, so it's not terribly expensive in
that regard these days, but it also takes time to get and compile stuff
every quarter, and time is expensive).  My current thought, not terribly
unlike the stow approach, is to have each tool in its own separate
directory by version, like /usr/local/<something>/perl/5.6, and then have
symlinks that point to the right binaries -- but name and update those
symlinks on a quarterly or per-project basis, so I have something like
/usr/local/2002q2/bin/perl or /usr/local/projname/bin/perl linked to the
appropriate versions.  This means that I need just one comprehensive tree
of tools and libraries (without the added effort of telling the tool that
it will live "here" but look like it lives "there") and many lightweight
directories of symlinks -- which themselves never need to be updated,
but merely duplicated and tweaked every quarter or for a new project.

Comments as well as alternative, and quite probably better, approaches
and ideas are very welcome.  Thanks in advance!


P.S. -- I just have to wonder why it's "splitting open" instead of
        "unfolding", since the latter would complement "folding" in 
        name as well as function...


:-D
-- 
David T-G                      * It's easier to fight for one's principles
(play) address@hidden * than to live up to them. -- fortune cookie
(work) address@hidden
http://www.justpickone.org/davidtg/    Shpx gur Pbzzhavpngvbaf Qrprapl Npg!

pgpKYM0lveTBS.pgp
Description: PGP signature