On Mon, 2007-03-05 at 11:28 -0500, Robin Norwood wrote: > Ralf Corsepius <rc040203@xxxxxxxxxx> writes: > > > On Mon, 2007-03-05 at 11:08 -0500, Robin Norwood wrote: > > [...] > > >> If we retroactively add a 'Provides: perl-devel' to versions of perl in > >> older distributions, will that help? > > It will solve the *.spec portability issue, but ... the core question > > still remains: Is this split "correct" and "sustainable" or simply > > broken? > > > > ATM, IMO, the outcome is still unclear. > > Yes, I meant assuming we decide to 'go forward' with this change. > > > E.g. wrt to the MakeMaker issue, the "correct solution" would be to let > > a ExtUtils::MakeMaker spec "Requires: perl-devel", and to let all > > perl-modules using ExtUtils::MakeMaker at build-time > > "BuildRequires: perl(ExtUtils::MakeMaker)". > > > > I had wanted to have deeper look into this problem throughout today, but > > haven't found the time for it (and my day is almost over). > > This definitely needs more attention. Well, as Joe pointed out (when he wasn't name-calling), CPAN does depend on ExtUtils::MakeMaker. So, we can do the following: * Move ExtUtils::MakeMaker to its own package. Move CPAN to its own package. Have the CPAN package depend on ExtUtils::MakeMaker, have the ExtUtils::MakeMaker package depend on perl-devel. In functionality, this brings us back to where we began, except that now, default installs (just perl) will not get CPAN. * Move ExtUtils::MakeMaker and CPAN to perl-devel. Again, default installs (just perl) won't get CPAN. * The third option is to move config.h back into perl, and document this as an exception case. ~spot
