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

Re: Reaction to Redhat/Fedora modified releases

Thread Previous | Thread Next
Nicholas Clark
January 25, 2012 03:11
Re: Reaction to Redhat/Fedora modified releases
Message ID:
On Wed, Jan 25, 2012 at 09:53:58AM +0100, Jerome Quelin wrote:
> On 12/01/24 13:54 -0500, David Golden wrote:
> > On Tue, Jan 24, 2012 at 12:54 PM, Jerome Quelin <> wrote:
> > > - 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?
> i'm not the one trying to shave everything possible, since i'm not
> working on the installation stage of the distribution. but i think that
> for them, every byte count (since it would allow to put more rpms on the
> installation cd). and they need perl on the cd since our installer is
> written in perl...

Specifically, on this point about installation CDs, IIRC Ubuntu are using
a compressed file system. Which means that we can't win by compressing
individual files in the (minimal) distribution and saying "ooh, fewer bytes",
because the size as needed on the CD doesn't decrease (and might actually
increase due to the overhead of having something not-compressible)

I was going to ask "Does Mageia Linux use a compressed file system?"
but I don't think that it actually matters. Flexibility costs - I think
that ultimately we don't have the resources (ie people) to come up with
two "perl-minimal"s, one optimised for byte size on disk, one optimised
for byte size when compressed. And as I suspect that for an install CD
a compressed file system is going to always "win", that suggests the choice
here is "optimise for byte size when compressed".

> in fact, the -devel package only ships all *.h files, and the following
> scripts: cpan dprofpp enc2xs h2xs json_pp libnetcfg piconv pl2pm
> pod2usage podchecker podselect prove psed pstruct shasum xsubpp
> nothing else.

Of those, it's a shame that cpan is there, and not in the main perl package.
This feels like spoiling the ship for a ha'porth of tar, given that it's
only 5K, and *everything* else needed to download and install pure-perl
modules is shipping in the main package.

> > 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)
> but this will not prevent conflicts between (using your naming scheme)
> perl-base and perl-$DUAL_LIFE_MODULE shipping a script.

It's a shame that RPM isn't as flexible as DEB, which (as I understand it)
has the system of "diverts", which solves this sort of problem.

And, if I understand what he's suggesting, it *does* prevent conflict.
In that, for each script concerned

1) The script *only* ships in perl-$DUAL_LIFE_MODULE
2) The perl-base package depends on each perl-$DUAL_LIFE_MODULE

because to install "perl" one would have to install all the pre-requisite
packages for the dual life modules, and that way one gets a full

Nicholas Clark

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