Re: perl breakage in Cooker mostly resolved

Den 06:00 20. januar 2012 skrev  <[email protected]> følgende:
>> Hi,
>> the most important perl related rebuilds have finished - urpmi is
>> working with 5.14 on my test box with the current packages.
>>
>> Updating now is no longer guaranteed to break things. ;)
>
>  I updated a few minutes ago, and did need to rebuild quite a few
> packages, because when perl-URPM was updated, and a few others,
> urpmi gone to restart, *but* it had not updated all urpmi and
> perl-URPM dependencies.
>
>> If you want to play it safe (yes, right. Sure you do. That's why you're
>> using Cooker in the first place ;) ), wait a bit longer.
>> If you rely heavily on perl code other than urpmi, wait a bit longer.
>> In particular if you're running a mail server that needs spamassassin
>> (which uses lots of different perl modules), wait a bit longer.
>>
>> If you're updating and running into problems, here's how to identify
>> and fix them:
>> In general, the symptom of breakages that can still occur is getting an
>> error message like
>> "undefined symbol: Perl_Gthr_key_ptr"
>> The fix is to identify the perl module is coming from, and simply
>> rebuild it.
>> e.g. if you see
>>
>> "/usr/bin/perl: symbol lookup error:
>> /usr/lib/perl5/vendor_perl/5.12.3/x86_64-linux-thread-multi/auto/List/MoreUtils/MoreUtils.so:
>> undefined symbol: Perl_Gthr_key_ptr"
>>
>> Check what package the module is from --
>>
>> [bero@localhost ~]$ rpm -qf
>> /usr/lib/perl5/vendor_perl/5.12.3/x86_64-linux-thread-multi/auto/List/MoreUtils/MoreUtils.so
>> perl-List-MoreUtils-0.320.0-1
>> [bero@localhost ~]$
>>
>> Then simply rebuild that package.
>
>  First rebuilds will fail to generate a package, and things
> may be trickier if one does not have build tools installed.
>
>  What I did was to go on some dependencies with something
> like:
>
> $ repsys co perl-Foo-Bar
> $ cd perl-Foo-Bar
> $ bm -l
> $ (cd BUILDROOT/perl-*; tar cf - . | (cd /; sudo tar xvf -) )
>
> and annotate what was built in the above steps in a text
> file, because would need some --nodeps for other packages,
> until it was able to generate a rpm, then would just install
> the rpm.
>
>> Needless to say, the fixed packages for all the modules still broken
>> will appear in the next couple of days. No need to report any such
>> breakage as a bug unless you run into it a week or two from now.
>
>  So, I did not follow closely how it was done in previous
> perl updates, but I believe it should have strict dependencies
> to force a single transaction, and not fall for the problem
> I just experienced, that was urpmi restarting before its
> dependencies were updated.
Currently perl packages gets a dependency like 'perl(abi) >= 5.12' generated,
but perl isn't backwards compatible for perl extensions built against
older versions
so generating strict version dependencies like 'perl(abi) = 5.12' for
perl extensions
should probably be sufficient in the future..

--
Regards,
Per Øyvind