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 > - Smaller buildsys size > - Introduces real perl-module build-deps instead of a dependency on a > "lumped-together" meta-rpm (=> improved long term stability of perl > module packages) > - The option to upgrade/replace "core perl modules". That pretty much covers it as far as I'm concerned. >> 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)". > > 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 -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching
