Bug 810510

Summary: Circular build dependency in perl-DateTime-0.70-3.fc18
Product: [Fedora] Fedora Reporter: Paul Howarth <paul>
Component: perl-DateTimeAssignee: Steven Pritchard <steve>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: iarnell, perl-devel, steve
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-16 17:46:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Paul Howarth 2012-04-06 13:35:26 UTC
DateTime has a hard dependency on DateTime::TimeZone and won't run without it. DateTime::TimeZone can be built without DateTime present but the resulting rpm package has a dependency on perl(DateTime) and hence cannot be used to bootstrap the perl-DateTime package.

My suggested fix is not to include perl(DateTime::TimeZone) as a build requirement when bootstrapping, and that in turn means the test suite cannot be run when bootstrapping. Since perl-DateTime needs special treatment for bootstrapping, you might as well also add perl(DateTime::Format::Strptime) as a buildreq when not bootstrapping:

diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index 24cf770..60f5a38 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -7,12 +7,14 @@ License:        Artistic 2.0
 Group:          Development/Libraries
 URL:            http://search.cpan.org/dist/DateTime/
 Source0:        http://www.cpan.org/authors/id/D/DR/DROLSKY/DateTime-%{version}.tar.gz
-# circular dependency - only used for one test
-#BuildRequires:  perl(DateTime::Format::Strptime) >= 1.2000
 BuildRequires:  perl(base)
 BuildRequires:  perl(constant)
 BuildRequires:  perl(DateTime::Locale) >= 0.41
+# Build requirements that themselves require DateTime
+%if 0%{!?perl_bootstrap:1}
+BuildRequires:  perl(DateTime::Format::Strptime) >= 1.2000
 BuildRequires:  perl(DateTime::TimeZone) >= 1.09
+%endif
 BuildRequires:  perl(Math::Round)
 BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(Params::Validate) >= 0.76
@@ -55,7 +57,10 @@ find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
 %{_fixperms} %{buildroot}/*
 
 %check
+# DateTime::TimeZone is a hard requirement of DateTime, but DateTime::TimeZone itself requires DateTime
+%if ! 0%{?perl_bootstrap:1}
 RELEASE_TESTING=1 ./Build test
+%endif
 
 %files
 %doc Changes CREDITS LICENSE README TODO



Other notes:

You could safely add the release test requirements, even when bootstrapping:

BuildRequires:  perl(Test::CPAN::Changes)
BuildRequires:  perl(Test::EOL)
BuildRequires:  perl(Test::NoTabs)
BuildRequires:  perl(Test::Pod) >= 1.14
BuildRequires:  perl(Test::Pod::Coverage) >= 1.08
BuildRequires:  perl(Test::Spelling), aspell-en


Latest upstream release is 0.74.

Comment 1 Iain Arnell 2012-04-06 15:35:41 UTC
I took care of the circular dependency when splitting DT::TZ out into a separate package last year - perl-DateTime-Timezone contains the bootstrapping logic to avoid {build,}requiring perl-DateTime.

Comment 2 Paul Howarth 2012-04-06 16:01:27 UTC
Ah yes, you've done it to avoid runtime deps too, which my script hadn't picked up. I think it's best to avoid hiding runtime deps when bootstrapping as it means that the bootstrapped binary package is different from a non-bootstrapped one, so to be safe we'd want to rebuild everything post-bootstrap that had pulled in DT::TZ to its buildroot during the bootstrap phase, in case the addition of DT itself caused a problem (admittedly that will be a short list in this case).

Anyway, I'll update my build-order script to reflect the way you've done it.

Comment 3 Paul Howarth 2012-04-16 17:46:44 UTC
It turns out that the only package built during the bootstrap phase that pulls in DT::TZ but not DT is perl-DateTime itself, so there's no issue here.