I've run into an interesting edge condition, caused a minor headache, and
figured out a simple solution.
If you start integrating a product, and run into headaches, sometimes these
WIP can end up sitting in /efs/dev for WEEKS while you work on the issues
getting them built correctly. During that entire development process, you
really ALREADY depend on the various releases and releasealiases which you
will eventually register as dependencies, but normally that is done AFTER
install, verify and archive.
The problem I just created was that I removed something I thought wasn't in
use, and then 2 days later when I looped back around to working on the
thing that was going to depend on it... Oops.
So, I'm going to move depends to the FRONT of the efsdeploy command list,
from near the back end, where it currently sits. This is being done for
the above discussed tactical reason, but also for some more important
strategic ones.
Now that I'm building massively large dependency trees with cpan2efs, and
maintaining them automatically (watching "cpan2efs --updateall" run makes
me smile -- I designed that way back in 2000!!), I'm seeing some patterns
emerge which enable yet another higher layer of automation. Currently,
the efsdeploy "depends" command just registers whatever dependencies you
have listed in efsdeploy.conf, metadata which is currently managed by the
user/admin by hand, or in the case of cpan2efs, at least *partially*
auto-generated.
In this next wave of hacks, "depends" will do some basic analysis of this
metadata, to enable us to do things like the following:
[-] Auto-updating dependencies to the "latest" release
I'd like to be able to specify my perl5 dependencies as follows:
[depends]
perl_runtime = perl5/Moose/latest
Where "latest" means that latest version available in
/efs/dist/perl5/Moose. The "depends" command will actually do a
point-in-time analysis of these specifications, and then essentially
"compile" a list of specific releases to use for building this release.
This is why "depends" will have to be the very first command performed
after "download". If you really want to tie something to a specific
Moose release, then you don't specify "latest". cpan2efs would use this
heavily....
The way this will work is that the "depends" command will generate
platform/compiler specific depends.conf files with the expanded and
analyzed releasealiases to be used for the remainder of the lifecycle of
this release. If you change efsdeploy.conf, then you'll need to
regenerate these files. I *might* have the depends.conf files depend on
the efsdeploy.conf file. Change the latter and you invalidate the former,
requiring them to be regenerated, which would clear the status of all the
subsequent commands. The downside is that tweaks and hacks to tune, say,
the install process, will force a complete rebuild, but I actually think
that's the right thing to do here. When I have to hack and beat on
efsdeploy.conf, or the hooks, to get something to build, then I always go
back and do a complete rebuild anyway, to make sure it REbuilds cleanly.
That's just good practice. This feature would essentially enforce that,
although it could get annoying.
Note that this will give us a chance to UP FRONT warn about the use of
deprecated releases, too.
[-] Automatically limiting the platforms and compilers
Now that I'm running into perl5 distros that simply don't work for one or
more platforms, or one or more compilers, I have extended efsdeploy.conf to
support a simpler means of specifying what to skip for a given build. The
next headache is that anything that depends on a module that skips, say
powerpc32.aix.6/5.14, will fail to build unless you also skip that specific
platform/compiler.
Well, there's no reason why "depends" can't analyze the dependencies,
inspect their efsdeploy.conf files (and you can probably to this analysis
for non-efsdeploy dependencies, too, by inspecting the contents), and
"inheriting" the skip lists.
Here's a real world, specific example: Class-Load-XS does NOT work with
powerpc32.aix.6/5.14. It fails miserably. It is also a required dependency
for Moose. Moose is a required dependency for a LOT of things. If
efsdeploy does NOT automate the generation of the skip lists, then you
suddenly find a very large portion of the CPAN distros no longer installing
automatically, and that means cpan2efs --updateall fails. That makes me
unhappy....
There's several other aspects of dependency management that I am
considering improving as well, as usual, based on real world problems that
I'm encountering as I take EFS to a much higher scale...
[-] Optional dependencies
Currently, if you specify a dependency, it's required. There are some
perl5 modules that need to skip a given platform, but if it's an optional
dependency for something else, then it would be nice to specify it as an
optional dependency, and then only use it on the platforms/compilers where
it IS available. In the case of Moose depending on Class-Load-XS, that's
required, so Moose has to skip whatever Class-Load-XS skips. Currently, if
an optional dependency skips a platform, then we either have to drop the
dependency, or skip that platform/compiler when building it's dependents.
When the optional dependencies enable advanced features in the dependent,
it would be nice enable those features on the platform/compilers where they
work, and just skip them where they don't.
[-] Platform specific dependencies
I am actually surprised that we've been able to get away with support for
these, but since we have always focused on maintaining things on multiple
platforms, it's a sign that we've done a very good job at it. Eventually,
we're going to need this, though.
_______________________________________________
EFS-dev mailing list
[email protected]
http://mailman.openefs.org/mailman/listinfo/efs-dev
