On 5/13/07, Jose Pedro Oliveira <jpo@xxxxxxxxxxxx> wrote:
Robin Norwood wrote:
> Ralf Corsepius <rc040203@xxxxxxxxxx> 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
