Since I know Steve is working on a bootstrap setup, let me just raise
a HUGE issue that anyone will run into. Until i solve it that is...
The cpan2efs infrastructure depends on the latest and greatest
functionality in several modules, in particular, it NEEDS the latest
ExtUtils::MakeMaker. However, this module has some very tricky
bootstrapping issues. First of all, just about everything IT depends
on also depends on EU::MM to be installed!! You can delete the
various EU::MM dependencies, but you will quicly find that you end up
having to delete it for almost everything, and that's not
maintainable.
The even bigger problem is that EU::MM bundles a LOT of the other
critical modules we need to use, and if they are installed alongside
EU::MM, then code that needs to use the properly installed versions of
those modules breaks, and breaks badly. I addressed this when I
found it by adding the missing dependencies expliticly in the
efsdeploy rules:
In Extutils-MakeMaker's depends.conf:
#
# ExtUtils-MakeMaker includes a lot of bundled CPAN distros, which we
# want it to NOT install. However, in order to make bootstrapping
# easy, Schwern doesn't list these as explicit dependencies, so we
# have to.
#
[runtime/required]
perl = \
perl5/CPAN-Meta \
perl5/CPAN-Meta-YAML \
perl5/ExtUtils-Command \
perl5/ExtUtils-Install \
perl5/ExtUtils-Manifest \
perl5/File-Copy-Recursive \
perl5/File-Temp \
perl5/JSON-PP \
perl5/Parse-CPAN-Meta \
perl5/Scalar-List-Utils \
perl5/Version-Requirements \
perl5/version
Problem: building each one of THOSE also depends on the new EU::MM!!!
I am currently exploring ways to handle this in the cpan2efs code.
For example, instead of reacting to the discovery of a circular
dependency, it might be possible to prevent them. If you discover a
dependency for a given module that is already in the dependency tree
(IOW, you discover a circular dependency), and the module in question
happens to be in the core (which is the case for EU::MM), then warn
about it, and then let that dependency be satisfied by the core.
This will require some significant changes to cpan2efs, though, since
it doesn't pass this information around the various recursive
subroutines that are busy expanding the tree.
Bear in mind that once you get to the point where you're ready to use
cpan2efs... You're going to be stuck until I figure this out.
Fortunately, I am blocking on this right now, so it has all of my
attention. Watch the commits for patches... Probably today, I hope.
_______________________________________________
EFS-dev mailing list
[email protected]
http://mailman.openefs.org/mailman/listinfo/efs-dev
