Front page | perl.perl5.porters |
Postings from January 2012
On 01/25/2012 09:53 AM, Jerome Quelin 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... > > In Fedora I was asked to make Perl smaller and cut dependencies, because our installer and main tools are in Python. Perl is not in the minimal set, but it's dependency of essential packages as vim, so it's on dvd. >>> 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. > We split packages into even smaller subsets, because we had also problems with updates of dual life modules. So in my perl-devel is only: enc2xs, h2xs, libnetcfg, perlivp. > >>> - 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. > I agree. perl-minimal could solve many packaging problems. Let's hear from non rpm distributions their opinions. > this would make my day. > thanks, > jérôme MarcelaThread Previous | Thread Next