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

Re: Reaction to Redhat/Fedora modified releases

Thread Previous | Thread Next
Jerome Quelin
January 25, 2012 00:53
Re: Reaction to Redhat/Fedora modified releases
Message ID:
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.


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

this would make my day.

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