Bug 643714

Created attachment 453927 [details]
record of "yum list setools*;yum install setools-libs-java.x86_64"

I'm wondering if this is an rpm problem?

The condition seems to be:
    If a new package is to be installed that has a dependency on another package that is already installed, but *newer* than the required dependency, then rpm will wrongly go for the still available i686 dependency instead of the x86_64 one.

See attached example of the same problem with setools-libs-java

Created attachment 453949 [details]
Make name based dependencies arch qualified where appropriate

Yep, I think this is just yum ending up picking the i686 version for non-arch-qualified dependencies for some reason.  Have you by chance customized yum's multilib_policy setting?

Anyway, the attached (untested) patch should work around it.  More info:
http://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires

No, no customized multilib-policy.  This system is based on a Fedora-14 Beta and being updated daily.  The problem started with the fedora-release switching from "updates-testing" to "updates" in the last couple of days.   The problem happens with multiple packages that had newer releases in updates-testing than are now visible in updates.

Thanks for the subversion-specific patch, but isn't this really a generic problem with yum or rpm?    It seems a shame to have to make the same fix to all packages.


There is no problem with arch dependencies if the *same* versions of the dependency and the new package are available.   The problem only happens if the installed dependency is newer than the package being installed.

It may very well be a problem with yum, but that's better discussed somewhere else where (more) yum developers are listening than this bug.  I can see it being difficult for the depsolver to satisfy all cases (sometimes there are conflicting interests) but making dependencies arch qualified like in my patch for subversion where appropriate would make the depsolver's job easier.

If it is intended that all Requires MUST be changed as indicated in the ArchSpecificRequires draft, else packages are expected to break, I'd expect that to be on a non-draft guideline.  Otherwise this seems like a regression in the package manager; reassigning to yum.

*** Bug 645670 has been marked as a duplicate of this bug. ***

> If it is intended that all Requires MUST be changed as indicated in the
> ArchSpecificRequires draft, else packages are expected to break, I'd expect
> that to be on a non-draft guideline.  Otherwise this seems like a regression in
> the package manager; reassigning to yum.

 If it was upto me, I would "MUST" all requires being arch specific where appropriate. But it isn't, mainly to lower the workload for packagers, and in a lot of cases it just works (hence the reason we lived without _isa for so long).
 However "automatic downgrades for requires" are a specific case where we've never "worked", and yum sees a free getout by just installing the other arch. because it's allowed to by the deps.

 The other problem that's always been there is:

yum install setools-libs.i686
yum install setools-libs-java.x86_64

...and nothing but using _isa will ever fix that (hence my desire for MUST), but again it's very rare for someone to do the above.

What about the case where installing

subversion-javahl-1.6.12-3.fc14.x86_64

which has "Requires: subversion = %{version}-%{release}"

ends up installing subversion.i686 rather than subversion.x86_64?  I can see the case about the arch-specific requires but it is surely a regression to do this by default? (i.e. it's going to break a whole load of stuff)

Shouldn't it be:

Requires: subversion(%{?_isa}) = %{version}-%{release}


Then you get the v-r AND the arch.


take a look at what subversion provides now:
subversion(x86-64) = 1.6.9-2.fc13
for x86_64

and
subversion(x86-32) = 1.6.9-2.fc13

for i686

Well, we are saying the same thing again.  Yes, I understand the case that the arch-specific requires should really be arch-specific, but historically the package manager has always DTRT with such unqualified requirements.  Breaking the historic behaviour BEFORE having a packaging guideline instructing us to fix all the arch-specific Requires seems like a regression in the package manager.  Is this argument not clear?  (even if you disagree)

(In reply to comment #9)
> Requires: subversion(%{?_isa}) = %{version}-%{release}

Just to clarify, the parentheses shouldn't be written here, they're included in the value of %{_isa}.

 Joe, yum does the right thing in the "normal" case ... but I'd assume the subversion problem is the same as the setools problem the user showed the data for in comment #1, they already have "subversion.x86_64 1.6.13-1.fc14" from updates-testing.
 So then yum sees "newpkg requires subversion = 1.6.12-3.fc14", subversion.x86_64 is already newer than that so it'd normally give up and tell the user. But subversion.i686 also fullfills the requirements, so it installs that.

 As I said, I didn't convince people that _isa should be MUST and so downgrades/manual-different-arch-installs will always fail in this way ... so AIUI either of you are free to ignore the BZ for your package, and the user can fix it by enabling testing more often (or using distro-sync) or you can add _isa and it'll just work, depending on preference.

 Actually, doesn't the last point cover both setools and subversion?:

  * A non-noarch subpackage's dependency on its main package or another subpackage (e.g., libfoo-devel depends on libfoo, or fooapp-plugins depends on foo-app).


  Packages MUST add the arch specific dependency in those cases.

Yes, but that's in the *draft*. I guess if the yum regression is not going to be fixed we will have to change all the packages ASAP.

 Joe, as I tried to explain before ... there are no known _regressions_ here, there are just cases that have always been bad and now we have _isa as a way to fix them.

 I will note that on F13 and F14 I currently get:

% yum ls subversion
Installed Packages
subversion.x86_64        1.6.9-2.fc13  @anaconda-InstallationRepo-201005130101.x86_64
Available Packages
subversion.i686          1.6.9-2.fc13  fedora                                   
subversion.x86_64        1.6.13-1.fc13 updates
% yum --releasever=14 ls subversion
Installed Packages
subversion.x86_64        1.6.9-2.fc13  @anaconda-InstallationRepo-201005130101.x86_64/13
Available Packages
subversion.i686          1.6.12-3.fc14 fedora                                   
subversion.x86_64        1.6.13-1.fc14 updates                                  

...which looks like something is treating subversion as multilib. for Fedora but not for updates. This is probably not helping :).

subversion-1.6.15-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/subversion-1.6.15-1.fc14

subversion-1.6.15-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update subversion'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/subversion-1.6.15-1.fc14

subversion-1.6.15-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.