Re: perl breakage in Cooker mostly resolved

d'oh, sent using wrong address..
Den 20:29 20. januar 2012 skrev Per Øyvind Karlsen <[email protected]> følgende:
> Den 19:56 20. januar 2012 skrev Jeffrey Johnson <[email protected]> følgende:
>>
>> 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.
> Notice that by "perl extensions" I refer to compiled, non-perl code
> such as ie. URPM.
>>
>> Narrowing the dependency range to a single version is entirely sane.
> Yes, for perl extensions.
> For pure perl modules OTOH it's sane enough with the existing
> dependencies generated as
> perl is built with support for loading these (and it's really just the
> versioned path for where the
> modules are installed and what perl is built for that dictates the
> version required for these,
> any other breakages between version upgrades isn't something we'll be
> able to easily track
> through packaging).
>>
>> 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.
> Seems overkill IMO, simple dependency on specific version series for
> perl extensions
> should be sufficient, while keeping what is for regular modules is sane and also
> prevents breakage for pure perl module packages between version
> version upgrades..
>
> --
> Regards,
> Per Øyvind