2011/8/15 Marcela Mašláňová <mmaslano@xxxxxxxxxx>: > > 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/perl-devel
