Bug 643714 - subversion-javahl-1.6.12-3.fc14.x86_64 has dependency on subversion.i686
Summary: subversion-javahl-1.6.12-3.fc14.x86_64 has dependency on subversion.i686
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: subversion
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 645670 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-17 14:50 UTC by John Ellson
Modified: 2014-01-21 23:16 UTC (History)
12 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2011-01-18 21:34:59 UTC


Attachments (Terms of Use)
record of "yum list setools*;yum install setools-libs-java.x86_64" (6.29 KB, text/plain)
2010-10-17 15:16 UTC, John Ellson
no flags Details
Make name based dependencies arch qualified where appropriate (4.15 KB, patch)
2010-10-17 18:48 UTC, Ville Skyttä
no flags Details | Diff

Description John Ellson 2010-10-17 14:50:50 UTC
Description of problem:
subversion-javahl.x86_64 has dependency on subversion.i686

Version-Release number of selected component (if applicable):
subversion-javahl-1.6.12-3.fc14

How reproducible:
100%

Steps to Reproduce:
1. yum install subversion-javahl.x86_64
2.
3.
  
Actual results:
Loaded plugins: presto, refresh-packagekit
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package subversion-javahl.x86_64 0:1.6.12-3.fc14 set to be installed
--> Processing Dependency: subversion = 1.6.12-3.fc14 for package: subversion-javahl-1.6.12-3.fc14.x86_64
--> Running transaction check
---> Package subversion.i686 0:1.6.12-3.fc14 set to be installed
--> Processing Dependency: libsqlite3.so.0 for package: subversion-1.6.12-3.fc14.i686
--> Processing Dependency: libpthread.so.0(GLIBC_2.0) for package: subversion-1.6.12-3.fc14.i686
--> Processing Dependency: libapr-1.so.0 for package: subversion-1.6.12-3.fc14.i686
--> Processing Dependency: libc.so.6 for package: subversion-1.6.12-3.fc14.i686

...

Expected results:
x86_64 rpms should have no i686 dependencies.

Additional info:

Comment 1 John Ellson 2010-10-17 15:16:47 UTC
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

Comment 2 Ville Skyttä 2010-10-17 18:48:59 UTC
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

Comment 3 John Ellson 2010-10-18 08:30:00 UTC
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.

Comment 4 Ville Skyttä 2010-10-20 16:10:54 UTC
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.

Comment 5 Joe Orton 2010-10-22 08:47:56 UTC
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.

Comment 6 Joe Orton 2010-10-22 08:50:28 UTC
*** Bug 645670 has been marked as a duplicate of this bug. ***

Comment 7 James Antill 2010-10-22 13:01:19 UTC
> 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.

Comment 8 Joe Orton 2010-10-22 15:48:30 UTC
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)

Comment 9 seth vidal 2010-10-22 15:57:04 UTC
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

Comment 10 Joe Orton 2010-10-22 16:19:51 UTC
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)

Comment 11 Ville Skyttä 2010-10-22 16:24:54 UTC
(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}.

Comment 12 James Antill 2010-10-22 16:27:45 UTC
 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.

Comment 13 James Antill 2010-10-22 16:30:43 UTC
 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.

Comment 14 Joe Orton 2010-11-12 10:15:55 UTC
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.

Comment 15 James Antill 2010-11-12 17:06:43 UTC
 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 :).

Comment 16 Fedora Update System 2011-01-04 14:36:28 UTC
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

Comment 17 Fedora Update System 2011-01-04 20:56:22 UTC
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

Comment 18 Fedora Update System 2011-01-18 21:34:42 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.