Re: [Help-stow] managing multiple versions of software tools

[David T-G]

Guillame, et al --

...and then Guillaume Morin said...
% 
% Hi David,

Hello!


% 
% Sorry for the delay...

Not a problem :-)  I've been fighting with compiling perl on HP and have
had plenty to keep me busy!


% 
% Dans un message du 12 Apr à  8:30, David T-G écrivait :
% > I tried to go to the savannah page to look at the mailing lists and, in
...
% 
% It seems to work atm, I guess it was a temporary problem.

Yeah.  Good.


% 
% > My current thought, not terribly unlike the stow approach, is to have
% > each tool in its own separate directory by version, like
...
% I think this is the right approach but I must admit that I've never been
% confronted to such needs, so I might be wrong :-) Anyway, this is
% something you can easily do with stow.

I wonder about that, and would like some clarification.  Here's where the
post will get a little bit long; please bear with me.  Again, the target
is to not only have a maintainable installation of lots of versions of
lots of software but to also make specific versions of specific tools
available to the users as a "collection" or a timestamped environment so
that we can know, with certainty, what someone used to develop a
particular piece of code while not duplicating entire installation trees
for every different project.

Let's take, for a moment, perl and gcc as our software tools.  For perl,
we'll imagine we have an old 5.004, the current 5.6.1, and 5.7.1 because
someone out there just has to have this new feature; all software
development before now was done with 5.004, today's default is 5.6.1,
and a particular project "radio" needs to use the 5.7.1 perl though it
uses the default version of everything else.  For gcc, let's say we have
2.7.2.2 (I think that's the old version), today's default is 2.95.2,
and we have 3.0.1 for a test project.

Installing the software is easy; given a repository directory somewhere
(let's just call it $REP), I can have

  $REP/
    gcc/
      2.7.2.2/
      2.95.2/
      3.0.1/
    perl/
      5.004/
      5.6.1/
        bin/
        HPUX/
          10/
            20/
              bin/
          11/
            11/
              bin/
        SunOS/
          5/
            6/
              bin/
            8/
              bin/
      5.7.1/

with the various bin and lib trees thereunder; each version-level
directory is a complete installation.  Note the generic-script-type bin
dir as well as the architecture-specific bin dir; I've only stretched it
out for perl 5.6.1, but you can imagine it for the others.

Now we don't want to have to put an entry for perl and an entry for
gcc and an entry for every other software tool that the user will want
to use into $PATH, so we have a dir of symlinks pointing to the real
installation, a la stow.  We can put each of those links dirs under
a common point and a user can just put a single dir tree in his path
and get everything.  So for our "legacy" and "today" (which we'll call
"2002q2") and "radio" projects, we'll have these directories (sorry for
the long display) with their links to the tools:

  $TOP/
    legacy/
      bin/
        perldoc -> $REP/perl/5.004/bin/perldoc
      HPUX/
        10/
          20/
            bin/
              perl -> $REP/perl/5.004/HPUX/10/20/bin/perl
        11/
          11/
            bin/
              perl -> $REP/perl/5.004/HPUX/11/11/bin/perl
      SunOS/
        5/
          6/
            bin/
              perl -> $REP/perl/5.004/SunOS/5/6/bin/perl
          8/
            bin/
              perl -> $REP/perl/5.004/SunOS/5/8/bin/perl
    2002q2/
      bin/
        perldoc -> $REP/perl/5.6.1/bin/perldoc
      HPUX/
        10/
          20/
            bin/
              perl -> $REP/perl/5.6.1/HPUX/10/20/bin/perl
        11/
          11/
            bin/
              perl -> $REP/perl/5.6.1/HPUX/11/11/bin/perl
      SunOS/
        5/
          6/
            bin/
              perl -> $REP/perl/5.6.1/SunOS/5/6/bin/perl
          8/
            bin/
              perl -> $REP/perl/5.6.1/SunOS/5/8/bin/perl

Users who need the legacy environment set PATH to $TOP/legacy (with some
magic architecture inclusion before the generic bin dir); users who are
doing current development set PATH to $TOP/2002q2 (same magic), and the
radio developer sets PATH to $REP/perl/5.7.1/(magic):$TOP/2002q2/(magic)
so that he finds his version of perl but the default version of everything
else.  If a project likes a given directory (eg 2002q2), it uses it;
if it has just one or two things to change (eg "radio"), it prepends
to $PATH.  If it has a sufficient number of changes (which could be just
one, to ensure that the development environment can be reproduced later
without digging through some old .cshrc file to see what was prepended),
we make a new $TOP/<name> tree with links pointing to the right places.

Now ... *gasp* ...  Here we come to where stow could help us -- maybe.
As you can see, once a link is made, it should never be broken; 2002q2
will *always* point to perl 5.6.1, and any other project will *always*
point to whatever version of perl (maybe 5.6.1 or maybe not).  The ability
to clear out all of the links belonging to a particular tool is of
marginal value (not bad, 'cuz we might change the official perl version
for a project, but not likely, either).  What we have is multiple PATH
trees (what most people have as /usr/local) which never need maintenance
and which might all point to the same software installation tree (a stow
directory or a repository) or might point to different installation trees.

Can stow, which will do a delightful job of making links and unfolding
directories and such, happily handle multiple PATH trees?  I recall a
bit in the documentation about stow not being able to fold/collapse a
tree if there were multiple stow installations because it couldn't know
with certainty what was owned by what if there were two hands messing in
the pot.  It seems that here we have the ultimate expression of that:
for a given tool (perl 5.6.1) we'll have a potentially huge number of
"owners".


% 
% HTH. Regards,

Thanks *very* much -- especially if you got all the way down here -- and
have a great day!


% 
% -- 
% Guillaume Morin <address@hidden>
% 
%                              La vie est facétieuse


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

pgpSufN2uYAsT.pgp
Description: PGP signature