Bug 207131
| Summary: | sane-backends dependencies "too wide" | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
| Component: | yum | Assignee: | Jeremy Katz <katzj> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5 | CC: | nobody+pnasrat, nphilipp |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-09-25 21:10:11 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Michal Jaegermann
2006-09-19 16:34:37 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. 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. meaning yum should only replace foo.x86_64 with bar.x86_64 (and not bar.i386) if bar obsoletes foo? "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? 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? |