On Tue, 2007-03-06 at 17:53 +0100, Ralf Corsepius wrote: > On Tue, 2007-03-06 at 11:44 -0500, Robin Norwood wrote: > > "Tom 'spot' Callaway" <tcallawa@xxxxxxxxxx> writes: > > > > > On Tue, 2007-03-06 at 14:31 +0100, Ralf Corsepius wrote: > > > > The new spec moves all of: ExtUtils::MakeMaker, ExtUtils::Embed, CPAN, > > > and Test::Harness into devel, along with the items that depend on them > > > (perlcc, perlivp, h2xs, libnetcfg). I put all of Encode back in base, > > > because it seemed like something that might get used by runtime perl > > > bits, but if you disagree, I'd like to know (I've not made up my mind > > > either way on that one). > > > > This seems like the right split to me - I'm still a little nervous about > > CPAN, but I think after people get used to it, it makes sense, and yum > > install perl(CPAN) should get it for them. I wonder if explicitly > > providing something called 'cpan' would help - so 'yum install cpan' > > would work as well. > The FPG mandates perl-CPAN as package name for the module if you would > want to split CPAN into a separate package (perl-ExtUtils-MakeMaker also > would make sense). > > However, pay attention to the versions being involved: > A perl-CPAN package would be required to carry the version of the CPAN > module, not the version of the perl-rpm. > > Unfortunately choosing different "versions" from inside of one spec > isn't easily doable from inside of one spec. Yeah, I considered doing that, but it would make the spec very ugly. I also considered splitting these items off into their own packages (in fact, I made them into their own packages, to ensure that I got all the bits into perl-devel. The concern about doing this was: A) perl would build its tools against the versions of these modules that we weren't packaging (we'd almost certainly end up with newer modules in dedicated packages). This could lead to bugs. B) It introduced circular dependencies, which we could work around, but I'd like to try to avoid. ~spot
