Front page | perl.perl5.porters |
Postings from January 2012
On Wed, 25 Jan 2012, Jerome Quelin wrote:
> On 12/01/24 13:54 -0500, David Golden wrote:
> > 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.
> 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.
In commit 00930d57002074c5f106f27d221b13e26f23dd31 , I have updated the
two illustrative lists of files for a minimal installation in INSTALL,
in the section on "Minimizing the Perl installation."
Beyond that, I'm not unsure how much useful generic guidance p5p can
really give for what distributors should include, since it depends on
what they hope to do with that minimal perl installation. For example,
consider two distributions that want to include a hypothetical
perl-minimal. One distribution has most of its installation programs
written in python, while the other mostly uses perl. It is unlikely that
they both need the same minimal files. It is also unlikely that p5p,
without knowing details of the perl installation scripts, can guess which
set of modules will be sufficient. Nor can p5p reliably guess the target
audience of the installed system in order to guess what they might need.
Independent of what files to include, there is the issue of what to name
such a stripped-down package. It would seem wise to me to pick a name
other than a plain 'perl.'
--
Andy Dougherty doughera@lafayette.edu
Thread Previous
|
Thread Next