Front page | perl.perl5.porters |
Postings from January 2012
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
Thread Previous
|
Thread Next