[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Bug 230608] missing config.h in latest -14



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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]