Bug 207131 - sane-backends dependencies "too wide"
Summary: sane-backends dependencies "too wide"
Status: CLOSED DUPLICATE of bug 200643
Alias: None
Product: Fedora
Classification: Fedora
Component: yum   
(Show other bugs)
Version: 5
Hardware: x86_64 Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-09-19 16:34 UTC by Michal Jaegermann
Modified: 2014-01-21 22:55 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-25 21:10:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michal Jaegermann 2006-09-19 16:34:37 UTC
Description of problem:

On x86_64 installation I had present only sane-backends.x86_64.
The latest update to sane-backends-1.0.18-2.fc5 resulted in yum
attempting the following:

use sane-backends-libs.x86_64 to replace sane-backends.x86_64
and sane-backends-libs.i386 to replace sane-backends.x86_64 (sic!)
and install for dependencies gphoto2.i386 (!!!)
and finally update for dependencies sane-backends.x86_64

The first and last step are clearly fine; the other two are spurious.

When I was complaining in bug #199600 that in a somewhat similar
situation yum misbehaves I was told that yum is fine and the problem
is caused by some unclear dependencies breakage in packaging.
Hence I assume that something like that is in play as well here.
Likely '.%{arch}' in dependency specificiations in .spec file should
be used or something similar.

To get around the problem one can do an explicit

   yum update sane-backends.x86_64

This does not try to pull additional i386 packages and once past
that hurdle 'yum update' does not have any further issues.

Version-Release number of selected component (if applicable):

Comment 1 Nils Philippsen 2006-09-20 08:18:32 UTC
I contest that this is a sane-backends packaging problem.

Yum doesn't update across architectures (e.g. it won't update an i386 glibc with
an i686 one), so it shouldn't resolve obsoletes across architectures as well,
even more so when the old package already gets obsoleted by a new package with
the same architecture as the old one. Mind that this (only obsoleting with the
same architecture) is the baheviour one would expect, thus the packager
shouldn't have to jump through hoops (obsoleting "package =
version-release.arch") to achieve it.

Changing component to yum.

Comment 2 Seth Vidal 2006-09-20 12:32:45 UTC
glibc, kernel are special. It will update any other package across archs within
the same biarch group:
ie: i686->i386 or i386->noarch, etc, etc

and name=ver.arch won't work in obsoletes anyway - they're not supported in rpm.

Comment 3 Nils Philippsen 2006-09-20 14:41:04 UTC
meaning yum should only replace foo.x86_64 with bar.x86_64 (and not bar.i386) if
bar obsoletes foo?

Comment 4 Michal Jaegermann 2006-09-20 16:08:25 UTC
"packagename.arch" appears to work just fine if passed to yum explicitely
so one would think that yum could do implicitely something like that
by itself when handling obsoletes.

I thought that an obstacle here is that, say, foo.i386 can be obsoleted
by bar.noarch or, probably more troublesome, the other way around.  This
happens.  But maybe "noarch" can be treated as an exceptional case;
or things are getting too complicated that way?

OTOH maybe this special casing is not needed at all and an implicit
".arch" for a package to be obsoleted, where this ".arch" is an
architecture of an installed package, would be just enough?

Comment 5 Seth Vidal 2006-09-24 21:57:52 UTC
it's not a function of what yum does.

obsoletes have no concept of arch in the header sense. Only in the color sense.

Paul, would you care to comment?

Comment 6 Jeremy Katz 2006-09-25 21:10:11 UTC

*** This bug has been marked as a duplicate of 200643 ***

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