Bug 200643 (yum-arch-obsolete)

Summary:	Obsoletes processing should be arch-aware
Product:	[Fedora] Fedora	Reporter:	Alexandre Oliva <oliva>
Component:	yum	Assignee:	James Antill <james.antill>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	davej, herrold, katzj, michal, nalin, nobody+pnasrat
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-03-12 13:54:12 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 Alexandre Oliva 2006-07-29 17:16:03 UTC

+++ This bug was initially created as a clone of Bug #200558 +++
(Reopening under the correct bugzilla id, sorry about the noise)

Description of problem:
If you have a repo containing packages for say both i386 and x86_64, and one
package available for both arches obsoletes another package that is installed
for only one of the arches, then both versions get installed.

Version-Release number of selected component (if applicable):
yum-2.9.3-2
rpm-4.4.2-31

How reproducible:
Every time

Steps to Reproduce:
1.Install random package x.{x86_64,i386,noarch}, doesn't matter
2.Build package y.i386 and y.x86_64, with Obsoletes: x
3.Create a yum repository with the y packages
4.Run yum update

Actual results:
Yum will install both y packages.

Expected results:
It would be nicer if it installed a package for the same arch or, failing that
because there's no such obsoletion package, the package in the arch most
suitable for the local configuration (in the example case, x86_64).

Additional info:

Comment 1 Alexandre Oliva 2006-07-29 17:17:59 UTC

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

Comment 2 Seth Vidal 2006-08-11 04:02:27 UTC

unless I'm mistaken - rpm obsoleting is not arch aware.

So yum cannot be.

Comment 3 Alexandre Oliva 2006-08-23 03:26:51 UTC

Maybe reassign to rpm, then?

Comment 4 Jeff Johnson 2006-08-26 04:12:35 UTC

Obsoletes is elf32/elf64 aware, this attribute is known as the "color".

The color used for Obsoletes is the union of all the colors of the files
contained in the header. The color of a file is 1 == ELF32, 2 == ELF64, otherwise 0.

Obsoletes are applied only to packages of the same color, or to colorless packages.

For a concrete example:

If a package foo.i386 contains elf32 files(so pkg color is 1)  with
    Obsoletes: bar
then the obsoletes applies to to bar.i386 (or perhaps bar.noarch), but not to bar.x86_64.

What yum does with Obsoletes: is a whole different story. yum (and up2date) use
obsoletes as a hint for package renaming, and choose to populate a transaction
with installs and erasures of packages according to their own algorithms.

The Actual results "Yum will install both y packages." is a failure in yum, not rpm.

This bug should be reassigned to yum.

Comment 5 Seth Vidal 2006-08-26 04:29:14 UTC

Is there anyway for any package manager to know w/o having access to the rpm
header what the color is?

If not, then what are the chances of having this information exported as a
single tag in the rpm header? 

If it is as simple as you claim then it would make sense, for accessibility of
the interface to export the value into a header tag.

Comment 6 Jeff Johnson 2006-08-26 04:48:08 UTC

A header extension could be done (rather than a tag) to compute the color if necessary.
Meanwhile, there are already methods to return object color for all the relevant objects.

There is little reason to statically save a color tag, with all the baggage necessary to get
a tag approved by LSB (note lack of RPMTAG_EPOCH in the LSB packaging spec, "Everything
that is not permitted is denied." is LSB's agenda). Luckily, a header extension behaves exactly
as a tag would.

I have no idea how you are going to get tag or extension without
a header, your question makes no sense because only headers have tags.

The package color can be easily computed by retrieving RPMTAG_FILECOLORS, an
array of ints. Then loop over all the ints, or'ing the values together.

The result is the package color.

FWIW, I've explained how colors are attached to the 4 primary objects within rpmlib
   rpmts
   rpmte
   rpmds
   rpmfi
to you several times before, clearly you were not listening.

All the above objects have colors computed from their file contents.

So an rpmfi color is the union of all the colors of the files contained within,
an rpmds object is the union of the colors of the files attached to dependencies,
etc etc.

And file color is exactly the same as file has ELF32MAGIC == 1, ELF64MAGIC == 2, otherwise 0.

Comment 7 Seth Vidal 2006-08-26 05:17:02 UTC

yes, I understood. I was just planning on including that output, if it is a
header extension into the xml.

Comment 8 Jeremy Katz 2006-09-25 21:10:25 UTC

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

Comment 9 Jeremy Katz 2007-04-25 18:50:30 UTC

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

Comment 10 Jeremy Katz 2007-04-25 19:24:53 UTC

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

Comment 11 Jeremy Katz 2007-04-30 18:47:14 UTC

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

Comment 12 Seth Vidal 2008-03-12 13:54:12 UTC

Yum has been changed to try and obsolete for a particular arch, if at all possible.

This won't work in every case and to be sure rpm has some interesting cases with
this operation, too.

closing as upstream