develooper Front page | perl.perl5.porters | Postings from January 2012

Re: Reaction to Redhat/Fedora modified releases

Thread Previous | Thread Next
David Golden
January 24, 2012 10:54
Re: Reaction to Redhat/Fedora modified releases
Message ID:
On Tue, Jan 24, 2012 at 12:54 PM, Jerome Quelin <> 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

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 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.  ( 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?

-- David

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About