Created attachment 598505 [details] {a,b,c}.spec as.tar.gz Description of problem: Obsoletes cannot be arch-specific. Version-Release number of selected component (if applicable): rpm-4.10.0-5.fc18.x86_64 How reproducible: Always. Steps to Reproduce: tar xzf abc.tar.gz for i in a b c;do rpmbuild -bb $i.spec;done rpm -i b-1-1.x86_64.rpm # correct: # error: Failed dependencies: # a(x86-64) is needed by b-1-1.x86_64 rpm -i a-1-1.x86_64.rpm rpm -i b-1-1.x86_64.rpm rpm -e b rpm -i c-1-1.x86_64.rpm rpm -q a c Actual results: a-1-1.x86_64 c-1-1.x86_64 Expected results: c-1-1.x86_64 Additional info: a.spec is normal b.spec: Requires: a%{?_isa} - _isa works for Requires c.spec: Obsoletes: a%{?_isa} - it is ignored with _isa; If I remove %{?_isa} it works.
Yes, obsoletes are a special case in that they are matched on package name alone, not provides like other dependencies. This is to avoid unwanted package removals when compatibility provides are present.
So if you consider 'Obsoletes' must not contain arch then there is a different bug: c.spec: Obsoletes: a Steps to Reproduce: # rpm -U a-1-1.i686.rpm # rpm -U c-1-1.x86_64.rpm # rpm -q a c Actual results: package a is not installed c-1-1.x86_64 Expected results: either: a-1-1.i686 c-1-1.x86_64 or: error: cannot obsolete non-matching arch: a-1-1.i686 for c-1-1.x86_64
Created attachment 601143 [details] a.spec and modified c.spec according to Comment 2 as .tar.gz
What you're seeing is the expected behavior- one needs to be able to obsolete packages of non-matching arch as well (eg bug 713323). However there *are* cases where you might not want that to happen... the actual issue is that there's no way for rpm to know what the packager wants, and no way for packagers to express it either.
Bug 713323 was fixed incorrectly. If a package is no longer multilib it should: %ifarch s390x %global otherisa (%{__isa_name}-32) %else #!s390x %ifarch ppc %global otherisa (%{__isa_name}-64) %else #!ppc %ifarch sparc64 ppc64 s390x x86_64 %global otherisa (%{__isa_name}-32) %endif #sparc64 ppc64 s390x x86_64 %endif #!ppc %endif #!s390x Obsoletes: pkgname%{otherisa} < 4-5%{?dist}
...and we come a full circle: that doesn't work, see comment #1.
Initially I did not fully parse it so in detail: (In reply to comment #1) > Yes, obsoletes are a special case in that they are matched on package name > alone, This is the problem, I have filed this defect as this Bug. > not provides like other dependencies. Cannot parse this, I guess you refer by 'provides' to some internal rpm processing or not? > This is to avoid unwanted > package removals when compatibility provides are present. Please be more specific and provide a testcase where my proposal does not work. I have provided you a testcase where the current rpm behavior does not work.
(In reply to comment #7) > Initially I did not fully parse it so in detail: > > (In reply to comment #1) > > Yes, obsoletes are a special case in that they are matched on package name > > alone, > > This is the problem, I have filed this defect as this Bug. Obviously, but the behavior is intentional. It's also spread all over the package management stack, not just rpm. > > not provides like other dependencies. > > Cannot parse this, I guess you refer by 'provides' to some internal rpm > processing or not? There's nothing "internal" about provides. Obsoletes match against what you see in 'rpm -qa', requires and conflicts match against what you see in 'rpm -qa --provides'. The provides are a (vast) superset of the plain package NEVR's, and matching obsoletes against obsoletes too much. > > This is to avoid unwanted > > package removals when compatibility provides are present. > > Please be more specific and provide a testcase where my proposal does not > work. > I have provided you a testcase where the current rpm behavior does not work. Obsoleting on provides would remove unwanted packages when you have eg package named "compat-foo" which provides "foo = <some version>", and another package with "Obsoletes: foo <= <some version>". Obsolete operates on packages as opposed to the capabilities provided by them, to avoid issues like this. And yes, the ISA-name of a package is a "capability", not the package itself.
(In reply to comment #8) > Obsolete operates on packages as opposed to the capabilities provided by > them, to avoid issues like this. OK, I agree this part is right. > And yes, the ISA-name of a package is a "capability", not the package itself. I believe this is the bug, the package itself should contain %{arch}. It may be a leftover from the days when rpm did not even have %{arch} in its default --qf. But today %{name}.i686 and %{name}.x86_64 are very different packages.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Is this bug still an issue. Should we change the release to a later version of Fedora?
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
We kinda ran into this again recently: pjones changed 'fwupdate' to no longer build on i686. It still builds on other arches, though. How do we obsolete it only for i686 installs, so the old packages are removed on upgrade of i686 installs?
Still the case in f33 - not being able to Obsolete only packages for given architecture: $ rpmbuild -ba iaito.spec error: line 45: Illegal char ')' (0x29) in: Obsoletes: r2cutter(x86-64) < 5.2.0 error: line 45: Only package names are allowed in Obsoletes: Obsoletes: r2cutter(x86-64) < 5.2.0 https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages While ve have instruction that explicit Provides: should be arch specific, the same should probably apply to Obsoletes: and would be nice to have relevant support in the rpm.
Renaming r2cutter package to iaito. Having in spec file: Obsoletes: r2cutter < 5.2.0 Provides: r2cutter%{?_isa} = %{version}-%{release} Obsoletes: r2cutter-devel < 5.2.0 Provides: r2cutter-devel%{?_isa} = %{version}-%{release} Even rpmlint complains when obsoletes is un-arched and provides arched: $ rpmlint iaito-5.2.0-1.fc33.src.rpm iaito-5.2.0-1.fc33.x86_64.rpm iaito-devel-5.2.0-1.fc33.x86_64.rpm iaito.x86_64: W: obsolete-not-provided r2cutter iaito-devel.x86_64: W: obsolete-not-provided r2cutter-devel
Changing this behavior would be risky business, as mentioned previously. That doesn't mean it can't ever happen (the use cases exists and are valid of course) but we'd have to come up with a scheme that doesn't break existing workflows. Either way, it's not something that would happen in Fedora specifically so closing now.