I almost got our of bed at 4AM to write this up.... That's when the idea
came to me, seriously....

In order to bootstrap a new EFS environment, we first compile EFS and it's
perl dependencies into /usr/efs, just tot eh 64bit platform, and use that to
get the new domain initialized.  Then, we compile that same pile of stuff
into /efs/dist/efs/core/bootstrap, for both the 32/64 bit platforms, and we
use that to build efsdeploy, then the compilers, then everything else.

Well, wouldn't it be nice if we could just take the stuff we have RIGHT NOW,
in /efs/dist, and somehow use THAT to bootstrap?   Obviously, you can't drop
it into an /efs/dist directory structure, but what if we were to do that
following.   Starting with a few "seed" MPRs, expand the entire dependency
tree, and starting from the bottom, create a single tarball that you can
unpack somewhere, and then just do this:

ln -s /path/to/where/you/unpacked /efs/boot

This would work, because when we create the tarball contents, we can apply
this simple change to each and every file:

    s{/efs/dist/}{/efs/boot/}gmsx;

Now, you will have a COMPLETE dependency tree for, say efs/core/x.y.z and
efs/deploy/a.b.c, and you can use THAT to get the initial domain
bootstrapped, and then just replace EVERYTHING in /efs/boot with real
releases in EFS by doing:

    efs download release efs core x.y.z
    efs download release efs deploy a.b.c

As soon we that finishes, then just remove /efs/boot, and the unpacked
bootstrap tarball.

Pretty cool, huh?   But wait...  We can use the SAME approach to guarantee
that our test environment matched the current runtime we're using.  Why did
Colin get burned when he ran through the bootstrap?  Because he used a
slightly older /usr/efs and the Moose version in /usr/efs was older than the
one you need for efs-core master.  This will solve that problem -- we can
regenerate the /efs/boot directory tree trivially, with a single command,
each time we get a new, stable release of efs/core in place.

We can create a test setup by doing the same thing -- create a localized
directory structure, that is based on /efs/test, which will allow us to
mirror ALL of the /efs/dist contents we need to run the test suite, and yet
still have an "empty" /efs/dev, and /efs/dist, for the purpose of the tests
themselves.

I'm going write EFS::Deploy::DependencyTree, based on the algorithms in
EFS::CPAN::DependencyTree, and implement an "export" method, than will do
exactly the above.

If it's not clear, here's how this would essentially be done, one MPR in the
dependency tree at a time.  Note that this is done for ONE platform, since
this is going to be installed locally to a single machine...

    mkdir /var/tmp/efs-boot-YYYYMMDD-HHMMSS
    cd to the above
    foreach mpr in $( list of mprs in the dependency tree )
        mkdir m/p/r/common
        ( cd /efs/dist/m/p/r/common && tar cf - . ) | ( cd m/p/r/common &&
tar xf - )
        mkdir m/p/r/.exec/$platform
        same tar pipeline
        use find() to replace /efs/dist/ with /efs/boot/ in ALL files

Now you just tar this up, into efs-boot-YYYYMMDD-HHMMSS.tar.gz, and we're
got a bootstrap package.

On the system you're using to bootstrap, now, you will not need ANY of the
locally installed dependencies.  None.  Well, we may decide to skip the
compilers, and anything else not strictly necessary for the boostrap
process.

Unpack the tarball, whereever you have space, and then make the /efs/boot
symlink.

We're going to get this export feature as a side effect of the development
of EFS::Deploy::DependencyTree, since that's the code that's going to
implement:

    efsdeploy_rebuild

This script's purpose in life?  To rebuild an ENTIRE dependency tree, from
the bottom up, adding whatever platforms and compilers are missing.  I
intend to add perl5.12 support to the existing /efs/dist/perl5 using this
approach, with basically one or two commands (if I can find the "tops" of
the perl5 dependency tree, then I can do it in one command -- it'll just
take a while, and stress Jerry's air conditioning).

This will be the same script that ports the contents of /efs/dist, in
general, to new *platforms*.  All we'll have to do is get the efsclient
ported, and get the compiler's bootstrapped, but I *might* be able to make
this code smart enough to even handle the compilers, too.

By the end of this year, when someone asks us to port to a new platform, or
add a new compiler, it's going to be VERY VERY easy.

This is fun.....
_______________________________________________
EFS-dev mailing list
[email protected]
http://mailman.openefs.org/mailman/listinfo/efs-dev

Reply via email to