On Thu, Nov 18, 2010 at 7:31 AM, demerphq <demerphq@gmail.com> wrote: > So, that seems to suggest to me that if we stored after install the > pod and full lib worth of modules in a compressed form, (and enhanced > perl and perldoc and etc to handle compressed files), that we would > actually end up with a smaller footprint than we would if we > *stripped* and did not compress, and we would have an even more > minimal footprint if we compressed the stripped release. Ah. I get it. That's true. I'm not sure it's a "win" for the end user, since browsing .pm(z?) files becomes a bit more cumbersome, but for pure .pod files it could make sense. Though as others have said, disk is cheap, so the size of perl *after* installation doesn't seem like a big deal. The motivator for a minimal perl that the Ubuntu/Debian guys raised was that they are trying to cram as many binary packages as possible onto a 700MB or so CD-ROM image. At that scale, giving them back 1% or so would actually be significant, I think. Assuming there are a few hundred packages on a CD-ROM, then perl's package size is significant. E.g. for Maverick -- package perl for i386 is 3.6M and depends on perl-base (.9M) and perl-modules(3.3M). perl-doc is an optional package and is 6.9M (contains *compressed* man pages for modules and all .pod files and the perldoc binary) Since they already split out pure documentation, the savings they would get would probably be in pod-stripping .pm and .pl files. I've already committed a patch to skip installing unnecessary .txt file from unicore, so if they backport that, they'll squeeze a bit more out. After that, the way they can really cut size will be to split out CORE (maybe into a perl-dev package) and drop the bigger Encode modules. Still, a stripped down perl might be useful for people who compile a separate perl for each application. -- DavidThread Previous | Thread Next