FWIW, I've discovered that while "make dist" fails in the scenario below, it does create the untarred directory you need to create the distribution.
Since I have EFS_PERL_DEPENDS_RUNTIME_GLOBAL exported, I just let it fail, and then just manually tar up the directory, which I can then copy elsewhere and install. It's still ugly, and if you don't like the workarounds, then YOU can debug M::I. I'm going to live with the ugliness for the time being, since it's not stopping me from making progress. Progress towards what exactly I don't know, but going anywhere is better than standing still. On Mon, Oct 18, 2010 at 7:48 AM, Phillip Moore <[email protected]>wrote: > When Module::Install is turning into a major issue for our development > workflow. > > First of all, if you've tried to install any of our git repos into /efs, > then you've already seen part of this problem. Since Module::Install is > not in the core, you have to tell perl where to find it, and it doesn't work > correctly, no matter what I've tried. > > In the boot.efs world, here's how we currently generate a tarball for > installation via efsdeploy. > > EFS_PERL_DEPENDS_RUNTIME=perl5/Module-Install/1.00 perl Makefile.PL > make manifest > PERL5LIB=/efs/dist/perl5/Module-Install/1.00/exec/5.10/lib/perl5 make dist > > This is very counter-intuitive. First of all, why not just > export EFS_PERL_DEPENDS_RUNTIME when you run make dist? Well, if you do > that, Module::Install doesn't work: > > /efs/dist/perl5/core/5.10.1-build020/.exec/x86-64.rhel.5/bin/perl "-Iinc" > -I. "-MModule::Install::Admin" -e "dist_preop(q(EFS-Deploy-0.999_034)\ > )" > Found extra file inc/Module/Install.pm > Found extra file inc/Module/Install/PRIVATE.pm > Found extra file inc/Module/Install/Fetch.pm > Found extra file inc/Module/Install/Share.pm > Found extra file inc/Module/Install/Can.pm > Found extra file inc/Module/Install/WriteAll.pm > Found extra file inc/Module/Install/Win32.pm > Found extra file inc/Module/Install/External.pm > Found extra file inc/Module/Install/Makefile.pm > Found extra file inc/Module/Install/Scripts.pm > Found extra file inc/Module/Install/Base.pm > Found extra file inc/Module/Install/Metadata.pm > > It appears that your MANIFEST does not contain the same components that > are currently in the 'inc' directory. > > Please try running 'make manifest' and then run 'make dist' again. > > Remember to use the MANIFEST.SKIP file to control things that should not > end up in your MANIFEST. See 'perldoc ExtUtils::Manifest' for details. > > The 'prompt' method does not exist in the 'inc' path! > Please remove the 'inc' directory and run -e again to load it. > make: *** [EFS-Deploy-0.999_034.tar.gz] Error 2 > > If you just set PERL5LIB as shown above, then you get a distribution > tarball you can use. IOW, that ugly hack works. > > But we're just working around the fact that Module::Install, as > implemented, seems to have a built in assumption that it's been installed in > the core, because if you DO install it into the perl5/core directories > (which is what we do during the bootstrap process), then it works fine. > > This has suddenly become a MAJOR headache, because in the test.efs setup > I'm using, I simply export EFS_PERL_DEPENDS_RUNTIME=efs/core/test, and > everything OTHER than building the distribution tarball works fine. In > order to get a tarball generated, now I have to do: > > ( unset EFS_PERL_DEPENDS_RUNTIME ; PERL5LIB=/efs/test/.... ; make dist ) > > This is really tedious, and while we can obviously write some simple shell > aliases to work around this, it would be nice to figure out why M::I is not > interacting with EPD and our perl setup very well. > > > >
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
