Front page | perl.perl5.porters |
Postings from February 2012
Re: Reaction to Redhat/Fedora modified releases
Thread Previous
|
Thread Next
From:
Todd Rinaldo
Date:
February 1, 2012 23:47
Subject:
Re: Reaction to Redhat/Fedora modified releases
Message ID:
E680356B-5027-441B-AC78-AB48DF39FD80@cpanel.net
On Jan 24, 2012, at 11:54 AM, Jerome Quelin wrote:
> hi,
>
> 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
> distribution...
>
>
> 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
> pointing
> . 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,
> etc)".
>
> 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,
> jérôme
I'm late to the discussion, but many of jérôme's comments mirror the major issues I've been dealing with for the past 2 years in creating an up to date perl distro via RPM. Paticularly the dual-life issue has kept me up nights. The approach I'm taking to the problem is to:
1. Exclude anything dual life in my perl-core package that will conflict with a CPAN version. This is mostly bin scripts.
2. Also strip html docs and man pages as they're duplicate to perldoc. (Is there an opinion on which forms of the docs need to be shipped with the product to comply with the license?)
3. Build all dual-life packages individually so they are up to date from CPAN.
4. make "perl" a meta RPM that simply requires in perl-core and each of the CPAN versions of the dual-life modules.
IMO, it would be cool if I could somehow tell Configure not to build/install anything that is dual-life. I'm not sure if a non-dual life perl would be stable enough to build the dual life modules if I did that. To me, this is the sanest approach to building out a core perl, allowing for dual-life modules to be updated separately. I don't think I could provide a patch in the short time before the coming code freezes for 5.16, but I was considering taking this project on for 5.18. I'm also not sure how such a patch would be received if I did make it, since p5p would then be providing a way to build a severely stripped down perl.
Thread Previous
|
Thread Next