ok, I'll nibble. (while avoiding the hook that Gabor is now on ;-)
heres some thoughts, unorganized.
we gotta think about structure and mechanism, else we devolve into
policy, and whos/whats on the build list.
1. kinds of dists:
microperl everything for make -f Makefile.micro
miniperl
bareperl what weve got now, minus dual-life modules
standardperl what weve got now
various extraperls what Gabor wants
2. bundling.
perhaps naively, id expect a series of tarballs, all of which get
unpacked sequentially into same directory. This implies you need
all the previous ones, presumably to provide files that are needed
for the build (forex: Configure)
For the most part, theyd stay off each others toes (minimized shared
files), and for the exceptions (why should there be exceptions ? maybe
temporary situation). But they do share directories, starting with ./
If filenames are shared/overlayed, they should be the same content if
possible. (Im thinking of Configure, which is needed for everything but
microperl, IIRC).
IIRC, cpio files can be concatenated into larger ones,
maybe tar files too, but not tar.gz files. Thats at least inconvienient
from a simplistic view.
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.
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.
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.
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.
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.
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.
microperl - nothing but essentials to build microperl target.
IE:
[jimc@harpo bleadperl]$ more Makefile.micro
LD = $(CC)
DEFINES = -DPERL_CORE -DPERL_MICRO -DSTANDARD_C -DPERL_USE_SAFE_PUTENV
OPTIMIZE =
CFLAGS = $(DEFINES) $(OPTIMIZE)
LIBS = -lm
_O = .o
ENV = env
all: microperl
O = uav$(_O) udeb$(_O) udoio$(_O) udoop$(_O) udump$(_O) \
uglobals$(_O) ugv$(_O) uhv$(_O) \
umg$(_O) uperlmain$(_O) uop$(_O) ureentr$(_O) \
upad$(_O) uperl$(_O) uperlio$(_O) uperly$(_O) upp$(_O) \
upp_ctl$(_O) upp_hot$(_O) upp_sys$(_O) upp_pack$(_O)
upp_sort$(_O) \
uregcomp$(_O) uregexec$(_O) urun$(_O) \
uscope$(_O) usv$(_O) utaint$(_O) utoke$(_O) \
unumeric$(_O) ulocale$(_O) \
uuniversal$(_O) uutf8$(_O) uutil$(_O) uperlapi$(_O) uxsutils$(_O)
plus whatever else is needed (early punt...)