Duplicate perl packages - perl-Compress-Raw-Zlib

Marcela Mašláňová mmaslano at redhat.com
Tue Aug 16 07:46:47 UTC 2011


On 08/16/2011 05:46 AM, Iain Arnell wrote:
> 2011/8/15 Marcela Mašláňová <mmaslano at redhat.com>:
>>
>> There are two solutions:
>> a/ don't ship sub-package from core perl and override them by package in
>> Fedora. This will work well for perl-Compress-Raw-Zlib - 2.033 in perl,
>> 2.037 in separated package, but we will have borken debuginfo.
> 
> Doesn't broken debuginfo only come into play if we install the package
> from cpan into core archlib directory. As long as we keep it in
> separate vendorarch, there's no problem.
> 
>> b/ remove dual life modules, which are outside of perl -> will solve
>> problem of broken debuginfo
>> https://bugzilla.redhat.com/show_bug.cgi?id=694704
>> Removal doesn't work for perl-Compress-Raw-Zlib, but it might work for
>> other packages. Core modules are now updated more often, so we might not
>> need dual life process.
> 
> Anything but this. We *will* end up wanting newer versions at some
> point and be forced to go back to using unwieldy patches in perl.spec
> again.
> 
>> Opinions? Better proposal?
> 
> Well, since Jesse then came back and wrote that koji doesn't seem to
> be affected after all:
>>
>> Upon further looking at the koji problem, these packages may not actually be causing my root issue, since they do come from separate SRPMs.
>>
> 
> How about option (c). Keep things just as they are?
> 
> Or if there is a problem with koji, how about (d) fix koji. It's a
> broken assumption that only binary sub-packages from a single source
> rpm can exist in an external repo (I use koji at work to build
> packages against SLES - Novell has a habit of releasing only affected
> sub-packages as updates - if they fix a problem that only affects
> bind-libs, for example, you'll only see a new bind-libs rpm in their
> updates repo and be expected to install that with the original base
> package. I'm fairly certain that I patched mergerepo to ignore this
> restriction).
> 
I suppose we can leave it as it is, but we should remove sub-packages
from perl if they are dual lifed. This would fix problem with debuginfo.
Perl package has only one debuginfo package for everything and dual life
debuginfo packages conflict with files from perl-debuginfo.

-- 
Marcela Mašláňová
BaseOS team Brno



More information about the perl-devel mailing list