Re: perl breakage in Cooker mostly resolved
Jeffrey Johnson <[email protected]> Fri, 20 Jan 2012 13:56:32 -0500
| Newsgroups | gmane.linux.mandrake.cooker.devel |
|---|---|
| Message-ID | <[email protected]> |
On Jan 20, 2012, at 1:10 PM, Per Øyvind Karlsen wrote: > Den 06:00 20. januar 2012 skrev <[email protected]> følgende: >>> >>> "/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. >> >> … >> 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.. > Writing a dependency assertion that is an "open-ended range" like Requires: perl(abi) >= 5.1 is a promise (in packaging) of future compatibility that is an irrational (but quite pleasant) lie: No one knows what abi going to be in future versions of perl. Narrowing the dependency range to a single version is entirely sane. But there is another technique, already in use by the kernel and ocaml and "buildid" in packaging, that is even better because the functionality can be reliably automated and with a narrower dependency assertion that is more precise. What would be needed to use in perl to detect a deletion in the perl abi of the symbol "Perl_Gthr_key_ptr" is this: 1) Extract all exposed external symbols that de facto constitute perl's ABI. 2) Sort the list of symbols, and compute the digest of the list of symbols. Use any digest: there are few security related issues for using a digest for "identification" rather than for an integrity check. but use SHA-4096 if you are concerned, all that is needed is uniqueness. 3) Generate the dependency (like kernel/ocaml packages do) as Requires: perl(abi) = <put the digest in hex here> 4) Test the results, examine the consequences, filter out symbols and/or split the single dependency into multiple dependencies, as needed. I expect that the above technique -- because it can be automated reliably -- to be increasingly important for *.rpm dependencies over the next few years. hth 73 de Jeff > -- > Regards, > Per Øyvind