Bug 810510 - Circular build dependency in perl-DateTime-0.70-3.fc18
Summary: Circular build dependency in perl-DateTime-0.70-3.fc18
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: perl-DateTime
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Steven Pritchard
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-06 13:35 UTC by Paul Howarth
Modified: 2012-04-16 17:46 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-16 17:46:44 UTC
Type: Bug


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.