[perl-Pod-Parser] 1.60 bump

[Paul Howarth]

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.