On 08/02/13 08:19, Petr Pisar wrote:
On Thu, Feb 07, 2013 at 04:11:08PM +0000, Paul Howarth wrote:
Hi Petr,
On 05/02/13 15:16, Petr Pisar wrote:
# Tests:
BuildRequires: perl(Test::More) >= 0.6
+%if !%{defined perl_bootstrap}
+# Break circular dependency Pod::Checker <-> Pod::Parser
+BuildRequires: perl(Pod::Checker) >= 1.40
+# Break circular dependency Pod::Usage <-> Pod::Select
+BuildRequires: perl(Pod::Usage)
+%endif
Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
...
%check
+%if %{defined perl_bootstrap}
+# Break circular dependency Pod::Usage <-> Pod::Select
+rm -f t/pod/headings.t
+%endif
make test
%files
%doc ANNOUNCE CHANGES README TODO
-%{_bindir}/*
+%if %{defined perl_bootstrap}
+# Break circular dependency Pod::Usage <-> Pod::Select
+%exclude %{_bindir}/podselect
+%else
+%{_bindir}/podselect
+%endif
These efforts to avoid a circular dependency between Pod::Parser and
Pod::Usage don't actually work because ExtUtils::MakeMaker requires
perl-podlators, which requires Pod::Usage, so it's pulled in anyway.
I know. Initially, I thought it will be necessary to upgrade Pod::Parser
without breaking build-root, but it turned out it was not necessary.
There are a number of dual-lived packages for which circular
dependencies seem to be quite unavoidable and need special treatment
when bootstrapping, e.g.:
I think it's not possible to bootstrap dual-lived core packages without core
perl sub-packages. Mainly because they are not written in the way.
Yes, that's the conclusion I came to as well.
One could split scripts from libraries which would help at least with
Pod::Usage, but I believe it would not fix all issues. Therefore I'm not
going to deal with breaking cycles in these packages. (Bootstrap on next
rebuild will enable dual-lived perl sub-packages, then it will rebuild
standalone dual-lived packages, and then it will disable dual-lived
sub-packages again. Therefore I guard the sub-packages with perl_bootstrap.)
Only problem I can see is what if a dual-lived package is already at a
higher version than the one that is bundled with the new perl? The
dual-lived package built for the old perl will then be wanted in the
buildroot when it comes to building the new packages but it'll have
broken dependencies because the old perl (and its MODULE_COMPAT) is no
longer available.
Paul.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
