Perl splitting

[Jose Pedro Oliveira]

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.

>> - Smaller buildsys size

   Hardly worth the effort as almost every perl package will require
   ExtUtils::MakeMaker and one or more of the Test 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)

   It will introduce maintenance problems in the long run as you
   continue to split core perl modules and also fail to follow the
   way upstream ships dual life perl modules (just look as
   ExtUtils::MakeMaker has been splitted in severeal sub-modules in
   recent years.

   Also perl 5.10 is around the corner and will "offer" you plenty
   more modules to be splitted (just think Module::Build and all its
   dependencies).

>> - The option to upgrade/replace "core perl modules".

   Can you give a concrete example of this?

> That pretty much covers it as far as I'm concerned.

   As it stands this change completely broke what I come to expect in
   every platform I have to work with perl (installing and support
   several perl apps).  As this change is to disruptive to me I will
   most likely start phasing out Fedora as my main linux platform
   (and losing interest in continuing supporting the Perl packages I
   maintain).


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


>>> 2) How did such a disruptive change got through Red-Eng as I haven't
>>>    seen it announced as a milestone for F7 ?
>>>    http://fedoraproject.org/wiki/CategoryFedora7Features
>> rel-eng would have to answer.
>>
>>> 3) Again how does this only gets committed this last weekend
>>>   (after the 4th test release)?
>> The split had been pending and discussed here for many weeks, but
>> progress on the perl package had been a snail. Some details had been
>> controversial, some details were broken, but 90% of the delays had been
>> caused by collaboration not working.
>
> A large part of the problem was that I was distracted with other Red Hat
> projects.  Also, I'm still very new at the whole packaging business, and
> had to rely on Spot and others for the bulk of the actual work here.
> So, I take full responsibility/blame for both the changes taking so
> long, and for them being pushed through so late.  My feeling was that it
> is better to move ahead with this, and suffer angry module owners, than
> to wait for yet another release for these improvements.
>
>> IMO, the currently split is only "half of the story" and far from being
>> complete.
>
> #1 on my list is to get rid of the 'perlmodcompat' mess early in the F8
> cycle.  If anyone knows of a situation where the modcompat stuff
> actually useful at this point, let me know.
>
>>> 4) How does a company plans to release a product with several
>>>    hundred packages broken (SRPMs that users won't be able to rebuild)?
>> Which harm does this to the Fedora run-time? It's a "grandfathering"
>> approach and it's actually not different from not performing an ordered
>> mass rebuilt.
>
> SRPMs can be rebuilt - the BuildRequires will be wrong, and the module
> authors will understandably be very annoyed with me, and will probably
> yell at me.  I can take it.
>
>> 1. In almost all cases you will see hard rebuild-breakdowns with obvious
>> "easy-fixes". In 90% of all cases all that would be required is to add
>> "BuildRequires: perl(ExtUtils::MakeMaker)" and (less frequent)
>> "BuildRequires: perl(Test::More)".

   I believe you are being a little optimistic here. While adding
   ExtUtils::MakeMaker is trivial, adding Test::More, Test::Simple,
   and Test::Builder* is not.

>> 2. Such issues could easily be approached by a perl-SWAT team, but ...
>>
>> 3. It's a grandfathering approach. There is no need to rebuild
>> everything.
>
> ^ What he said.
>
> -RN
>

jpo
-- 
José Pedro Oliveira
* mailto:jpo at di.uminho.pt * http://gsd.di.uminho.pt/members/jpo/ *