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
>
> 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.
>
I dont much like idea of authors/** in the core-dist.
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 ;-)
>>
>>
>> 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.
>
indeed. but CPANTs itself is untrusted, its a large group of unknowable
types,
who have no *fiduciary* responsibility to report honestly.
Its also plagued by false positives when prerequisites are not in-place.
>> 4. 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
>
jimc
> 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
>
> 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.
>
I dont much like idea of authors/** in the core-dist.
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 ;-)
>>
>>
>> 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.
>
indeed. but CPANTs itself is untrusted, its a large group of unknowable
types,
who have no *fiduciary* responsibility to report honestly.
Its also plagued by false positives when prerequisites are not in-place.
>> 4. 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
>
jimc