Front page | perl.perl5.porters |
Postings from January 2012
On 25 January 2012 09:53, Jerome Quelin <jquelin@gmail.com> wrote: > On 12/01/24 13:54 -0500, David Golden wrote: >> On Tue, Jan 24, 2012 at 12:54 PM, Jerome Quelin <jquelin@gmail.com> 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. (version.pm 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. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next