Perl splitting

[Chris Weyl]

On 5/13/07, Jose Pedro Oliveira <jpo at di.uminho.pt> wrote:
> Robin Norwood wrote:
> > Ralf Corsepius <rc040203 at freenet.de> writes:
> >
> >> On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote:
> >>> Hi,
> >>>
> >>> As I have been rather busy in the past months I haven't had the time
> >>> to follow the mailing lists and only this weekend did I realize that
> >>> the disruptive [1] change of splitting perl had been pushed through.
> >>>
> >>> Questions:
> >> Disclaimer: All answer are my personal view and opinion.
> >>
> >>> 1) What exactly do we gain with such splitting?
> >> - Smaller install size
>
>    Does this justify breaking what people come to expect in a
>    perl runtime environment, i.e., that every perl core module is
>    available?
>
>    Isn't people loosing perspective by just looking at the packaging
>    side of the question?  This kind of change breaks end user code as
>    the Test and CPAN/ExtUtils::MakeMaker modules are no longer installed
>    by default.

I raised this issue (and a number of the others you bring up) a while
back; hopefully you'll get more traction with this than I did :(

I'm not entirely sure why we're so focused on substituting our
judgement for the perl team's as to what constitutes a core module,
aside from some perverse fixation on breaking things and making life
more difficult for everyone that touches anything perl in Fedora.
--especially this late in the F7 release cycle!

I mean, really, what _actual_ problem are we trying to solve with this
split?  What are we trying to fix here?

> >> - Smaller buildsys size
>
>    Hardly worth the effort as almost every perl package will require
>    ExtUtils::MakeMaker and one or more of the Test modules.

And the splitted modules are hardly huge by any measure.  I doubt it's
unreasonable to claim there's more overhead in the additional rpm
transactions/depsolving needed to handle installing the additional
packages needed to supply these core modules.

> >> - Introduces real perl-module build-deps instead of a dependency on a
> >> "lumped-together" meta-rpm (=> improved long term stability of perl
> >> module packages)

I don't think it's fair to call perl a "meta-rpm", for a variety of
obvious reasons.  And even if the core perl tarball is a
"meta-tarball", then at least its metaness is owned by a core perl
team tasked with its maintenance.

[...snip...]

>    This change also pollutes the perl specfiles with additional BR
>    (perl core modules) and goes against what we have been doing for
>    the last 3+ years (at least since Fedora.US).

This has been an issue in reviews lately.  People are packaging perl
modules, and then being told "go add BR's on these core modules, but
not those".  It's confusing -- personally I feel like this split has
taken a relatively well understood, straightforward process and made
it fairly muddy -- shades of the recent review process changes.

I asked it above, but it's worth reiterating:  what _actual_problem_
are we fixing with this split?  Is it worth it?

                                               -Chris
-- 
Chris Weyl
Ex astris, scientia