develooper Front page | perl.perl5.porters | Postings from November 2010

Re: BRANCH dagolden/install-stripped -- Add install-stripped targetto Makefile.SH

Thread Previous | Thread Next
From:
David Golden
Date:
November 18, 2010 04:54
Subject:
Re: BRANCH dagolden/install-stripped -- Add install-stripped targetto Makefile.SH
Message ID:
AANLkTimX-Ts9+68SSagrS1BX+uWHug6V_6Sfz4SjfwUe@mail.gmail.com
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.

-- David

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About