On Sat, 2007-03-03 at 07:44 +0100, Ralf Corsepius wrote: > On Sat, 2007-03-03 at 00:13 -0600, Tom 'spot' Callaway wrote: > > On Sat, 2007-03-03 at 06:20 +0100, Ralf Corsepius wrote: > > > On Fri, 2007-03-02 at 11:28 -0500, Jesse Keating wrote: > > > > On Friday 02 March 2007 11:17:24 Tom 'spot' Callaway wrote: > > > > > I don't see any fault in adding perl-devel to the FC7 buildroot, with > > > > > the caveat that it will not be there in FC8+. Thoughts? > > > > > > > > I'd rather not change things multiple times. > > > Well, exactly the reason why I would like to see perl-devel in FC7's > > > buildroot. It avoids forcing packagers to change their packages NOW. > > > > > > Remember: Adding perl-devel to the buildroot affects one person (you). > > > Not adding it and affects 100s of packages and dozens of packagers. > > > > > > > Why does Ralf think it hasn't been baked yet? I'm missing that context. > > > > > > This change causes most (all?) perl modules and applications using perl > > > (comprising noarch packages) to depend on perl's config.h at build time. > > > > > > The primary question to clarify would be: > > > > > > What is the cause, why (esp. noarch) perl-modules now require a c-header > > > (perl's config.h) and (thereby gcc) to build? [1] > > > > Well, fwiw, they seem to have required this before, the -devel split > > just made it more apparent. > > I just tried to investigate on of my currently broken packages, and see > a file dependency on config.h in ExtUtils::MakeMaker generated > Makefiles. I've found at least one packaging-bug wrt. the perl-devel split-out, along the lines of what I wrote above: There is an indirect circular build-time dependency between "perl" and "perl-devel", for ExtUtils::MakeMaker based packages: Proof: * ExtUtils::MakeMaker based perl-modules contain a hidden built-time dependency through their Makefile.PL containing: use ExtUtils::MakeMaker; * ExtUtils::MakeMaker has a dependency on "config.h" # grep -R config.h /usr/lib/perl5/5.8.8/ExtUtils /usr/lib/perl5/5.8.8/ExtUtils/MM_Unix.pm:CONFIGDEP = $(PERL_ARCHLIB)$(DFSEP)Config.pm $(PERL_INC)$(DFSEP)config.h /usr/lib/perl5/5.8.8/ExtUtils/MM_Unix.pm: -f $self->catfile($dir,"config_h.SH") /usr/lib/perl5/5.8.8/ExtUtils/MM_Unix.pm:# We do NOT just update config.h because that is not sufficient. /usr/lib/perl5/5.8.8/ExtUtils/MM_Unix.pm:# An out of date config.h is not fatal but complains loudly! /usr/lib/perl5/5.8.8/ExtUtils/MM_Unix.pm:$(PERL_INC)/config.h: $(PERL_SRC)/config.sh /usr/lib/perl5/5.8.8/ExtUtils/MM_Unix.pm: -$(NOECHO) $(ECHO) "Warning: $(PERL_INC)/config.h out of date with $(PERL_SRC)/config.sh"; false * config.h is part of perl-devel => circular dependency between "perl" and "perl-devel" I.e. in a perfect world all MakeMaker-based perl-packages should BuildRequires: perl(ExtUtils::MakeMaker) and perl(ExtUtils::MakeMaker) would have to Require: perl-devel So, one approach I could imagine, would be to split out ExtUtils::MakeMaker from the main perl package. Ralf
