Front page | perl.perl5.porters |
Postings from January 2012
On Tue, Jan 24, 2012 at 12:54 PM, Jerome Quelin <jquelin@gmail.com> wrote: > we are also splitting perl in various sub-packages for various issues: > > - size: we provide a perl-base package stripped to the bare minimum to > reduce installation footprint on install cd How "bare minimum" are you talking about? Does every byte count or would a 30% reduction be enough? > - traditional split of libs and include: perl-devel package ship them to > follow the convention used for other libs (eg bzip2 / bzip2-devel) > > - traditional split of doc: perl-doc package ship them to follow the > convention used for other big packages > > - dual-lifing: this one is the real problem to me. > [snip] > what does it mean wrt current discussion? > - size: perl rpm package is requiring the perl-base, so installing perl > will ship a perl as p5p understands it... I think that could make sense. I could imagine a "perl" package that depends on "perl-minimal", "perl-doc", "perl-devel" and possibly "perl-$DUAL_LIFE_MODULE" so that the latter could be upgraded as necessary. If p5p can define the splits in a standard way, that could help standardize across OS packaging. > - devel split: ... except for this one, but i can live with adding a > require on perl-devel from perl package if p5p really wants to. I think this is tricky. There are some obvious "devel" things in the core , such as libperl.a and C headers in the lib/$VERSION/$ARCH/CORE directory. libperl.a can probably be removed except for when perl is compiled staticly. Removing the headers would prevent XS module installation. The *Perl* libraries are less obvious. Yes, EU::MM is a "devel" tool, but it's also the standard way to do other things as well, such as safely parse a "$VERSION =" string out of arbitrary perl code. Lots of other toolchain modules have dual uses along those lines. > - doc split: ... and except for this one also, but i can also live with > adding a require on perl-doc from perl package if p5p really wants to. Keep in mind that diagnostics.pm requires pod/perldiag.pod to be present. (hat tip: Nicholas for reminding me on #p5p) > - dual-life with scripts: i have the following options: > . use alternatives: pita to repackage > . append $VERSION to scripts in perl-Module-FooBar: may break new > scripts, and also can have the same licensing problem you're > pointing > . remove from perl rpm: licensing problem you're pointing out. I don't know the packaging details, but I would think you have to do a full dependency tree and have "perl-base" (or whatever) actually depend on "perl-minimal" (without dual-life) and packages for each dual-life module. There will be a few crazy exceptions that might not work well that way. (version.pm comes to mind) > so, what i would really like from p5p is a real stripped down perl to > the bare minimum. just the modules needed to install, but without the > whole "resolve dependencies / fetch missing from cpan (http, ftp, rsync, > etc)". Here's thing -- that's really not where the fat is. $ cd ~/perl5/perlbrew/perls/perl-5.14.2 $ du --summarize . 70024 . $ du -S | sort -rn | head -20 10140 ./man/man1 8636 ./man/man3 7300 ./lib/5.14.2/pod 4324 ./lib/5.14.2/x86_64-linux/CORE 2808 ./lib/5.14.2/x86_64-linux/auto/Encode/JP 2504 ./lib/5.14.2/x86_64-linux/auto/Encode/KR 2172 ./lib/5.14.2/x86_64-linux/auto/Encode/CN 2104 ./lib/5.14.2/x86_64-linux/auto/Encode/TW 2100 ./bin 1760 ./lib/5.14.2 1676 ./lib/5.14.2/Unicode/Collate 1204 ./lib/5.14.2/x86_64-linux/auto/Unicode/Collate 1196 ./lib/5.14.2/Module 1080 ./lib/5.14.2/unicore 1032 ./lib/5.14.2/x86_64-linux 852 ./lib/5.14.2/unicore/lib/Blk 776 ./lib/5.14.2/unicore/To 736 ./lib/5.14.2/x86_64-linux/auto/POSIX 648 ./lib/5.14.2/ExtUtils 644 ./lib/5.14.2/Pod The 20th item is less than 1% of the total. So all the headache and hassle for you and users trying to chop up the rest of the libraries gives you really tiny returns on that effort. I mentioned on #p5p that splitting out Encode into separate distributions so that the Asian language encodings are optional might be a big win for OS packagers. If you cut out man pages (27% of the total) and then cut out most of pod (except perldiag), the Asian encodings and CORE (collectively about 30%), then you can more than halve the size of perl with fairly minimal effort and minimal loss of functionality. (Admittedly, I'm talking uncompressed numbers here, but the point should stand). So my question is: would that be enough? -- DavidThread Previous | Thread Next