Description of problem: F14's repository currently contains 2 perl-version packages: download.fedora.redhat.com/pub/fedora/linux/development/14/i386/os/Packages/perl-version-0.82-128.fc14.noarch.rpm download.fedora.redhat.com/pub/fedora/linux/development/14/i386/os/Packages/perl-version-0.82-1.fc14.i686.rpm rsp.: download.fedora.redhat.com/pub/fedora/linux/development/14/i386/x86_64/Packages/perl-version-0.82-128.fc14.noarch.rpm download.fedora.redhat.com/pub/fedora/linux/development/14/x86_64/os/Packages/perl-version-0.82-1.fc14.x86_64.rpm Expected results: The repositories to contain only one version of a package. Additional info: perl-version used to be one of the dual lived perl-modules (being built as part of the main perl package and as a separate package). Seemingly (and incomprehensible to me) the separate perl-version package was orphaned in Fedora > 13. => the perl-version package which is being built separately _must_ be removed from the repo. # rpm -q --qf '%{name}-%{version}-%{release}.%{arch}: %{SOURCERPM}\n' \ -p perl-version-0.82-1* perl-version-0.82-128.fc14.noarch: perl-5.12.1-128.fc14.src.rpm perl-version-0.82-1.fc14.i686: perl-version-0.82-1.fc14.src.rpm => perl-version-0.82.1.fc14.<arch>.rpm needs to be removed (Yet another case of repomanage not being able to handle arch/noarch changes?)
No, it's just that no one asked for perl-version to be blocked. In fact, it was asked to be *unblocked*. C.f. https://fedorahosted.org/rel-eng/ticket/3729
Errr, ... well, facts are: * We currently have 2 versions of perl-version*.rpm in each Fedora 14 repo perl-version-0.82-128.<arch>.rpm and perl-version-0.82-1.noarch.rpm This also is visible at runtime: # repoquery perl-version perl-version-3:0.82-1.fc14.i686 perl-version-3:0.82-128.fc14.noarch * Fedora 13's repomanage is not able to cleanup this I don't know if and how this impacts yum. * https://admin.fedoraproject.org/pkgdb/acls/name/perl-version tells: Fedora devel orphan Deprecated Fedora 14 orphan Deprecated Fedora 13 mmaslano Fedora 12 mmaslano My conclusion from this: We have several issue interacting at once: * Marcela has seems to be wanting perl-version to be provided by the main perl's perl-version subpackage (== perl-version-0.82-128.fc14.noarch) for Fedora >= 14. * rel-eng has a problem in composing the repo * repomanage is defective (Long standing and known bug).
(In reply to comment #2) > My conclusion from this: We have several issue interacting at once: > * Marcela has seems to be wanting perl-version to be provided by the main > perl's perl-version subpackage (== perl-version-0.82-128.fc14.noarch) for > Fedora >= 14. > > * rel-eng has a problem in composing the repo The only 'composing' problem is that rel-eng did what the perl maintianers asked them to do, which is what led to the duplicate package. I'm treating this as a normal 'block this package in dist-f14', and have done so.
The only problem here is noarch/i686 arch. This module is dual lived and if it would be in both RPMs as noarch, everything would work just fine.
(In reply to comment #4) > The only problem here is noarch/i686 arch. As I tried to elaborate, there are more problems to it. > This module is dual lived It was dual lived until perl-version was orphaned n the packagedb for fedora-14 and for rawhide. => It is dual lived for fedora <= 13 but it is *not dual lived* for Fedora >= 14 Reopening - Marcela and Bill need to sort out things.
(In reply to comment #4) > The only problem here is noarch/i686 arch. This module is dual lived and if it > would be in both RPMs as noarch, everything would work just fine. perl-version is not a noarch package though - it includes XS code (at least the one on CPAN does, if not the one bundled with perl).
The perl.spec package does not contain any XS code (version::vxs) for unknown reason. So from point of view of original sources, it's clearly all right to be noarch from perl.spec and arch from perl-version.spec.
(In reply to comment #5) > (In reply to comment #4) > > The only problem here is noarch/i686 arch. > As I tried to elaborate, there are more problems to it. > Where did you elaborate? Did you mean: > perl-version-3:0.82-1.fc14.i686 > perl-version-3:0.82-128.fc14.noarch > * Fedora 13's repomanage is not able to cleanup this > I don't know if and how this impacts yum. This is valid state. The binary packages differ in release number (1, 128). If there is a problem with repomanage, it's a bug in repomanage. > * rel-eng has a problem in composing the repo Bill Nottingham said there was no problem: > The only 'composing' problem is that rel-eng did what the perl maintianers > asked them to do, which is what led to the duplicate package. Ralf, could you enlighten me what's the problem despite buggy repomanage tool which out of scope of this bug report?
perl-version.noarch is a subpackage of perl while perl-version.%arch comes on its own. After the latest perl updates there are now in repos perl-version-0.82-142.fc14.noarch.rpm with a build date "Thu 10 Mar 2011" and perl-5.12.3-142.fc14.src.rpm for its source package AND also perl-version-0.88-1.fc14.%arch.rpm built on "Fri 04 Feb 2011" from perl-version-0.88-1.fc14.src.rpm. These packages are similar to an extent but not the same as an %arch variant provides vxs.so missing from a "generic" one. Currently package versions are enough far apart to prevent a "perl-version ping-pong" but I do not see what can possibly enforce that property. It is really not clear why perl-version.noarch needs to be build with perl. It appears that Fedora 15 may end up affected in the same way.
(In reply to comment #9) > These packages are similar to an extent but not the same as an %arch variant > provides vxs.so missing from a "generic" one. == bug These packages are supposed to be identical but their %version and %release rsp. the versions of perl modules inside.
(In reply to comment #10) > > These packages are supposed to be identical but their %version and %release > rsp. the versions of perl modules inside. They are definitely not identical as %arch package supplies vxs.so and vxs.pm and it hard to imagine how a binary vxs.so would fit into a "noarch" variant. Here is a difference in listings: +/usr/lib64/perl5/auto/version +/usr/lib64/perl5/auto/version/vxs +/usr/lib64/perl5/auto/version/vxs/vxs.so +/usr/lib64/perl5/version +/usr/lib64/perl5/version/Internals.pod +/usr/lib64/perl5/version.pm +/usr/lib64/perl5/version.pod +/usr/lib64/perl5/version/vxs.pm +/usr/share/doc/perl-version-0.88 +/usr/share/doc/perl-version-0.88/Changes +/usr/share/doc/perl-version-0.88/README /usr/share/man/man3/version.3pm.gz /usr/share/man/man3/version::Internals.3pm.gz -/usr/share/perl5/version -/usr/share/perl5/version/Internals.pod -/usr/share/perl5/version.pm -/usr/share/perl5/version.pod Location changes for various .pod and .pm are not so essential but vxs.pm also shows up only in one of these.
We need a specification defining package upgrade. Especially whether arch part of release string creates independent upgrade paths. E.g. i686 package cannot supersede x86_64 package, e.g. noarch package cannot supersede i686 package (and vice versa). Recent addition of %_isa string to architecture specific dependencies into packaging guidelines hints this is allowed. Thus I infer it's legal to mix arch and noarch packages in one package name line. OTOH I'm curious how yum/rpm handled multiarch packages. Do you remember affair with replacing perl{-libs}.{i686,x86_64}? Frankly, I hate balancing between fuzzy specification and buggy implementation. Reason I do not want to block standalone perl-version is request for upgrade emerges in the future (latest upgrade has been forced by perl-Module-Build upgrade that lot of people consider as a must) and that results in unblocking the package and that reintroduces this situation again. And following which Fedora release prefers standalone or bundled perl-version incarnation is just current ping-pong problem moved into higher level. In other words this is not a solution.
I don't think arch/noarch is a problem per se; I'm curious though as to why the perl(version) bundled with perl itself doesn't include the XS code; if it did, it would be an arch-specific package again and there would be no noarch/arch ambiguity.
(In reply to comment #13) > I don't think arch/noarch is a problem per se; I'm curious though as to why the > perl(version) bundled with perl itself doesn't include the XS code; if it did, > it would be an arch-specific package again and there would be no noarch/arch > ambiguity. Core perl version doesn't have its own XS code because the necessary functions are included in universal.c and end up in libperl itself.
(In reply to comment #14) > (In reply to comment #13) > > I don't think arch/noarch is a problem per se; I'm curious though as to why the > > perl(version) bundled with perl itself doesn't include the XS code; if it did, > > it would be an arch-specific package again and there would be no noarch/arch > > ambiguity. > > Core perl version doesn't have its own XS code because the necessary functions > are included in universal.c and end up in libperl itself. So there's actually nothing wrong with the situation as it is then - as long as we can assume that vxs.pm is "private" to perl(version) and not to be presumed to exist by any other module?
(In reply to comment #15) > So there's actually nothing wrong with the situation as it is then - as long as > we can assume that vxs.pm is "private" to perl(version) and not to be presumed > to exist by any other module? Absolutely. vxs.pm is definitely private to CPAN's version. And even with CPAN's version, there's no guarantee that vxs.pm will exist; if you install without a c compiler (or specifically ask for it), you'll get pure-perl vpp.pm instead. It's an implementation detail that really shouldn't be visible at all. I'm really struggling to see what the real problem is here. Does anyone have an actual problem upgrading from perl-version-0.82-158.fc16.noarch (from perl core) to perl-version-0.88-2.fc15.%arch (from CPAN)? Or does anyone anticipate a problem when the reverse happens with perl-5.14 and we go from perl-version-0.88-2.fc15.%arch (from CPAN) to perl-version-0.88-199.fc16.noarch (from core)? Is anything actually broken? Or is this purely a cosmetic issue that our repositories contain two different versions of perl-version? and that repomanage then lists both packages because they're different archs? If so, I'd suggest fixing (or enhancing) mash so that it drops the older binary rpm when duplicates exist.
I agree with Paul and Iain. I can confirm I can perform downgrade and upgrade between these two packages fluently. I will unexport perl(version::vxs) from the standalone package Provides to signal vsx is not for public use.
perl-version-0.88-3.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/perl-version-0.88-3.fc15
perl-version-0.88-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/perl-version-0.88-2.fc14
perl-version-0.82-2.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/perl-version-0.82-2.fc13
(In reply to comment #16) > I'm really struggling to see what the real problem is here. At this moment the latest "upgrade" to perl-version-0.82-142 is plainly ignored because sometimes in the past perl-version-0.88 (this one %arch specific) was picked up by yum and installed. In other words this bundled one is just superflous and it is hard to guess why it is there. A possible issue may surface if a version of this bundled one was jumped to, say, 0.90 (no idea how these versions are picked). Then an upgrade would remove vxs.so and vxs.pm potentially breaking some installed modules using those. That may get "fixed" by bumping high enough a version on another package and da capo al fine. So right now just a mess in repos and a possible trouble waiting to happen but nothing broken immediately. Not much more.
(In reply to comment #21) > At this moment the latest "upgrade" to perl-version-0.82-142 is plainly ignored > because sometimes in the past perl-version-0.88 (this one %arch specific) was > picked up by yum and installed. That's the intention. The perl-version-0.82-142 package is part of perl core. Some other change elsewhere in the core perl package meant that all of perl's sub-packages got release bumped. It doesn't mean that perl-version-0.82-142 is better than perl-version-0.88, only that it's chronologically "newer". We still want perl-version-0.88 to be installed on end-user systems. > In other words this bundled one is just > superflous and it is hard to guess why it is there. Yes, perl-version-0.82 is superfluous today. But as it's a dual-lifed module, it's entirely possible that when perl 5.14.0 is released, it comes with an even newer version of perl-version. In that case, we could have perl-version-0.90-199 (for example) from core perl-5.14.0 rpm, while the separately packaged CPAN version is still at 0.88. Mosttimes (hows that for a new word?), CPAN has newer versions of modules than core perl, but sometimes core perl has the newer version. > A possible issue may surface if a version of this bundled one was jumped to, > say, 0.90 (no idea how these versions are picked). That's exactly what we want. If core perl suddenly appears with 0.90, we want to have it, even thought the CPAN still only has 0.88. > Then an upgrade would > remove vxs.so and vxs.pm potentially breaking some installed modules using > those. As I've already stated, vxs.{so,pm} is an internal implementation detail that should not be visible. Anyone expecting them to exist is already in for a world of hurt as they simply don't exist in core. > That may get "fixed" by bumping high enough a version on another > package and da capo al fine. Bumping to "fix" it would just hide an underlying problem. Absolutely nothing should use version::vxs directly (or, if it does, it needs to be prepared to cope with core perl where only version exists, and with crippled systems where version::vpp is used instead). > So right now just a mess in repos and a possible trouble waiting to happen but > nothing broken immediately. Not much more. Agreed. It is slightly messy that both packages exist in the repository, but even if only one were present, we still want to be able to flip-flop between the two different packages. And please, can we switch discussion to perl-IO-Compress in future. It's also dual-lifed and exists in fedora repos with both arch and noarch versions (and has done for nearly a year now). It's a lot less confusing to talk about IO-Compress versions than it is about *version* versions.
Package perl-version-0.88-2.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-version-0.88-2.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/perl-version-0.88-2.fc14 then log in and leave karma (feedback).
perl-version-0.88-3.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
perl-version-0.88-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
perl-version-0.82-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.