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

Re: Reaction to Redhat/Fedora modified releases

Thread Previous | Thread Next
Jerome Quelin
January 24, 2012 09:53
Re: Reaction to Redhat/Fedora modified releases
Message ID:

On 12/01/24 11:29 -0500, David Golden wrote:
> I think it's easier to do (b) if we do (a) nicely and say "come help
> us understand what you want" instead of guessing.  E,g, Debian/Ubuntu
> people were concerned about total size. (EU::MM doesn't really make a
> huge difference on that front).  Otherwise, we might do (b) and then
> find that it still doesn't serve and we're back to (a) but now with
> wasted time and probably more ire all around.

i'm the perl packager for mageia linux. here's the status on our

we are also splitting perl in various sub-packages for various issues:

- size: we provide a perl-base package stripped to the bare minimum to
  reduce installation footprint on install cd

- traditional split of libs and include: perl-devel package ship them to
  follow the convention used for other libs (eg bzip2 / bzip2-devel)

- traditional split of doc: perl-doc package ship them to follow the
  convention used for other big packages

- dual-lifing: this one is the real problem to me. some modules are
  dual-lifed on cpan, and upgrade can be a problem if the module
  provides scripts. indeed, although modules are splitted in @INC
  depending on core/vendor/site, the same is not true for scripts.
  example: EUMM ships instmodsh. perl rpm therefore ships this script.
  but EUMM is dual-lifed, and we provide it in perl-ExtUtils-MakeMaker
  rpm. to prevent /usr/bin/instmodsh to conflict if one wants the latest
  & greatest EUMM, i had to rename instmodsh in perl-EUMM as
  instmodsh.$VERSION. for some other less important modules, i removed
  the modules from perl rpm, but require or suggest the splitted module
  from perl rpm (this approach does not work for modules needed to
  install others, such as EUMM). i could also use the alternative schema
  to manage multiple implementations by different modules, but it's not
  really nice given the number of scripts shipped by modules 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...

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

- doc split: ... and except for this one also, but i can also live with
  adding a require on perl-doc from perl package if p5p really wants to.

- 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
    . remove from perl rpm: licensing problem you're pointing out.

so, what i would really like from p5p is a real stripped down perl to
the bare minimum. just the modules needed to install, but without the
whole "resolve dependencies / fetch missing from cpan (http, ftp, rsync,

if you p5p guys could ship this, it would really make my life easier...
and since jesse was talking about that in his roadmap, and that rjbs
didn't specifically remove this possibility, i definitely would like to
see this going live.

hoping this helps the discussion,

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