On Sun, 2007-05-13 at 18:40 +0100, Jose Pedro Oliveira wrote:
Robin Norwood wrote:
> Ralf Corsepius <rc040203(a)freenet.de> writes:
>> On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote:
>>> 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  change of splitting perl had been pushed through.
>> 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
Yes. Sometimes it's time to break with old habits.
Isn't people loosing perspective by just looking at the
side of the question? This kind of change breaks end user code as
the Test and CPAN/ExtUtils::MakeMaker modules are no longer installed
Where is the problem?
perl had been sloppily packaged in former Fedora releases, now things
are being cleaned up.
>> - Smaller buildsys size
Hardly worth the effort as almost every perl package will require
ExtUtils::MakeMaker and one or more of the Test modules.
Yes, but ... how many
_users_ do really need ExtUtils::MakeMaker or
Test:: modules? Perl devs will, normal users won't except when other
package will pull them in.
>> - Introduces real perl-module build-deps instead of a
dependency on a
>> "lumped-together" meta-rpm (=> improved long term stability of
>> 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
I don't see this as a problem. The rpms a perl module might be
in might change, but this should not affect a perl's module's dep on
other modules. If they do, then perl has broken compatibility and we
would be facing similar issues elsewhere.
Also perl 5.10 is around the corner and will "offer" you
more modules to be splitted (just think Module::Build and all its
Yes. Module::Build and friends are on my radar. They are amongst
reasons for why I said "this split is far from being complete".
>> - The option to upgrade/replace "core perl
Can you give a concrete example of this?
Check this list's archive. There
repeatedly have been such requests.
Before the split, it was technically impossible to replace core perl
modules, now we at least have the option to do so for those modules
which have been split out.
>>> 4) How does a company plans to release a product with
>>> hundred packages broken (SRPMs that users won't be able to rebuild)?
>> Which harm does this to the Fedora run-time? It's a
>> approach and it's actually not different from not performing an ordered
>> mass rebuilt.
> SRPMs can be rebuilt -
That's an urban legend. All rpms in Fedora have
been built against a set
of packages that had been valid (and were reported to work) at one point
in time. Even the mass-rebuilds in previous releases didn't actually
change much about this, because they were _unsorted_ rebuilds.
the BuildRequires will be wrong, and the module
> authors will understandably be very annoyed with me, and will probably
> yell at me.
I have no idea what you are referring to.
In case a user complains about an srpm you maintain not being
rebuildable, you (the rpm-maintainer) can choose to fix it (essentially
what "grandfathering" means - Fix upon request or need) or ignore this
In case an rpm's maintainer complains when he rebuilds a package he had
not touched for ages. Shall he update his spec, like he would have been
forced to do during a mass rebuild.
In case a perl-module author complains, ... I don't see how this is of
any importance here.
>> 1. In almost all cases you will see hard rebuild-breakdowns
>> "easy-fixes". In 90% of all cases all that would be required is to
>> "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.
Then let me put it this way: I haven't
encountered any case where fixing
had not been possible (and actually can imagine any situation where this
would not be possible).
In 90% of those cases I've adjusted it, it was adding "BuildRequires:
perl(ExtUtils::MakeMaker)" (because most perl dists use EU:MM) and
adding "perl(Test::More)" (for those case shipping testcases, almost all
of EU::MM based dists).
>> 2. Such issues could easily be approached by a perl-SWAT
team, but ...
I find it remarkable that none of you commented on this.