On Sun, 2007-05-13 at 18:40 +0100, Jose Pedro Oliveira 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? Yes. Sometimes it's time to break with old habits. > 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. 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 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. I don't see this as a problem. The rpms a perl module might be located 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 plenty > more modules to be splitted (just think Module::Build and all its > dependencies). Yes. Module::Build and friends are on my radar. They are amongst the reasons for why I said "this split is far from being complete". > >> - The option to upgrade/replace "core perl modules". > > 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 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 - 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 complaint. 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 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. 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. Ralf
