Duplicate perl packages - perl-Compress-Raw-Zlib

[Iain Arnell]

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).

-- 
Iain.