Gabor Szabo wrote:
On Sun, 9 Jan 2005, Jim Cromie wrote:
2b. standardperl would use the CPAN version of the dual-life modules.
the objective here would be to include CPAN.pm or CPANPLUS.pm,
and to include either a repository tree (with all the authors/?/??/* intermediate directories) which contains the current-coredist tarballs,
or (simpler) a single directory with all those dual-life packages in their tarball form.
OK, can someone please explain what is the story with the dual-life modules ? As I understand these have both CPAN and perl-x.x.x versions.
yes. IIUC.
What is the difference ? What is the process that happens today when the autor updates his CPAN version ? What if the porters change something in the module ? Which modules are dual-life ?
the basic difference is double the work, at least the uninteresting parts where you retest, repackage, etc. IOW, PITA (Pain in the arse)
today, the author/maintainer releases to CPAN (on his own schedule I think),
and submits to p5p. Theyre usually accepted w/o harangue, but thats probably
cuz maintainers work hard to prevent that from being an issue.
if porters change something besides integration into core-dist, author re-releases at some point.
As to whats dual-life, I dont know of a definitive list, but heres a few: Storable, Math::BigInt, Data::Dumper, Encode, Getopt, Memoize PathTools (was Cwd & File::Spec - bundled into 1 cuz of mutual dependencies) probly most things in ext/* are dual-life, many things in lib/* could be, with varying paybacks and costs.
wrt the PITA, Id note for example that core-dist has both lib/Storable.pm and ext/Storable/Storable.pm ; theres some reason. one of the PITAs (or maybe its a clue) is where the tests are - forex: lib/Filter/Simple/t/*.t vs where theyd be in a separate dist-file
I dont much like idea of authors/** in the core-dist.
In this maxiPerl thing I started I take a standard perl, unzip it, create a subdir called CPAN (clever name, eg ? :) and copy the unzipped versions of the tarballs of the modules. moving to at authors/?/??/* structure might make sense. I put it on the think about list.
The whole structure is there cuz CPAN is big, and some OSs have
poor directory traversal properties when a single directory has >1000 entries.
the only problem with that name is it is somewhat overloaded. weve got lib/CPAN, CPAN itself, and parts of cpan in your, well, CPAN directories: keep_source_where /usr/local/cpan/sources cpan_home /usr/local/cpan build_dir /usr/local/cpan/build
2a. (NB - this happens before 2b above, but is easier to clarify with above previously stated)
bareperl-overlay.tgz would be the modules that are not yet dual-lifed (sic). Id expect it to be ext/* and lib/* only, and only part of them. One would expect bareperl to shrink, as more core-dist modules are dual-lifed.
2c. now all the maxi-varieties are simple to package, essentially repeating 2b with different lists. They differ by being separable from the source tree of standard-perl.
I see you are on the same hook. ;)
I cant hear you, nyah, nyah :-P ;-)
Obviously the same mechanism should support both in-tree and out-tree bundles. out-of-tree is essential so that several maxi-dists can package
the same module. We dont want everyone squabbling about where DBI belongs. Certainly some common subsets are apparent, or will emerge.
What do you mean by in-tree and out-tree ?
the 2 setups for dual-life modules. more specifically, it reflects the layout
(placement, organization) of the various files in core-dist vs separate module-dist.
The re-packaging of tarballs within tarballs looks a bit silly, but it has an important function; it means that packages on CPAN are EXACTLY whats in a maxi-dist, which should lower the barrier to banks/etc taking them piecemeal; theyre already in an 'approved' package, with verifiably identical MD5 checksums.
I am not sure if that's important as the whole maxiPerl package will have its own checksum and it need to be trusted.
the checksum of an NT install disk is verifyable, That doesnt mean you trust it, or should install it. :-O
forex: if IBM were to rubber-stamp (say) DBI, they would do so with
a given version, along with DBD::DB2 (the module for their database).
Essentially, the bank is paying IBM for a list (and the verification & approval
process behind it), they can pull it from CPAN
knowing that the checksum matches that on the list.
By not publishing the list, IBM can bill other banks for same, and amortize the cost of developing a list across multiple customers. The work to improve modules on the list is still however a public benefit.
But if the package looks like this
./bareperl-x.x.x ./CPAN/authors/?/??/* ./CPAN/installer_script
Then we also keep the exact same perl distros as were created by the pumking with its original checksum.
*YES*, with comments above. the installer script, and its preinstalled config, are the 1st step to this. Im glad youve started it ;-)
indeed. but CPANTs itself is untrusted, its a large group of unknowable types,
3. Phalanx, CPANTS
Phalanx-100 sure looks like a strong candidate for one of the maxi-dists.
Devel-Cover affords some opportunity to put numbers on quality,
leading to possibility of q50, q60 grades on maxi-dists.
Forex, a maxi-web-q90-dist would have all web-related distributions
that pass a coverage threshold.
Yes, its putting too much faith in numbers, but at least thats clear from the arbitrary q-factor in dist-name.
CPANTS is probably worth a mention - there, check that off.
I don't think we can use Coverage as indicator, CPANTS might have better chances as it will, at some point, weight in lots of various factors, maybe including the Coverage report.
who have no *fiduciary* responsibility to report honestly.
Its also plagued by false positives when prerequisites are not in-place.
jimc4. somewhere along the line, these banks gotta just suck up the fact that they could pay IBM to bless some subset of CPAN. Id imagine that IBM would outsource some of it to authors and such.
Amen
Gabor
