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

Re: Reaction to Redhat/Fedora modified releases

Thread Previous | Thread Next
January 25, 2012 01:06
Re: Reaction to Redhat/Fedora modified releases
Message ID:
On 25 January 2012 09:53, 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...
>> > 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.
> definitely.
>> > - 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.
> 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.
>> > - 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)
> but this will not prevent conflicts between (using your naming scheme)
> perl-base and perl-$DUAL_LIFE_MODULE shipping a script.
> so, is having a p5p stripped down perl with just perl and (almost) no
> modules be possible? then we ship this as perl-minimal, all the modules
> as perl-$MODULE the way we are doing it for cpan-only modules, and we
> create a perl metapackage requiring all the modules that p5p think
> should be part of a standard install.

Thanks a lot for your feedback Jerome. I think it is very interesting
and useful insight.

Further insight from other re-distributors is also helpful.


perl -Mre=debug -e "/just|another|perl|hacker/"

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