sundialsvc4 has asked for the wisdom of the Perl Monks concerning the following question:
The prevailing wisdom, discussed recently here, is that you can simply use the autobundle command to snapshot your present installation, then install Bundle::whatever in order to replicate your installation. But my experience is that ... this is neither true, nor efficient.
(1) The autobundle may include components that are built-in to the Perl distribution. An attempt to install them, which is carried-out by the process of installing the bundle, will fail ... and, when it does, the entire autobundle-install will grind to a halt.
(2) The ordering of the modules in the autobundle is simply alphabetic. Thus, modules like YAML, upon which so many other modules depend, will not be installed until nearly dead-last, and every install preceding it will not perceive that it is there, because indeed it is not there yet. If the modules build themselves in different ways based upon what is and is not available, as many of them do, it becomes necessary to force(!!!) install the bundle, at least twice if not more.
Edit: (3) If a newer version of Perl is being installed alongside an older one, all of the CPAN libraries which rely upon XS code must be reinstalled into the local directory, even if other libraries already exist. (These would probably be compatible only with the older Perl, and its various co-dependencies, etc.) In this case, it is even more important that modules be compiled in the proper order and that the “older Perl” @INC directories not be searched.
This is, shall we say, “conduct not becoming a fine language of good breeding,” which, as we all know, Perl is.
What I am looking for, therefore, is a tool that will “sanitize” an autobundle, both to remove built-ins from the list and to optimize the order of the list so that dependencies are installed early. The process of re-creating a CPAN, e.g. after having upgraded Perl, ought to be a very clean and dependable procedure. Surely, it is. What am I missing?