Bug 213260

Summary: depsolver "reduced installs:" choosing wrong packages
Product: [Fedora] Fedora Reporter: Paul Howarth <paul>
Component: yumAssignee: James Antill <james.antill>
Status: CLOSED INSUFFICIENT_DATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: opensource
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-03 20:18:05 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:
Attachments:
Description Flags
mock root.log with yum-3.0-6
none
mock root.log with modified yum-3.0-6
none
mock root.log with modified yum-3.0-6 and explicit exclusion of selinux-policy from core repo none

Description Paul Howarth 2006-10-31 15:07:53 UTC
Description of problem:
I am attempting to build SELinux policy module packages for an FC5 target using
a mock buildsystem on FC6, with yum 3.0-6. One of the build requirements for the
policy module package is "selinux-policy-devel". Since upgrading my buildsystem
to FC6 with yum 3.0, "selinux-policy-devel" is not getting installed into the
buildroot as required - just "selinux-policy". Examining the mock root.log file
reveals that the correct selinux-policy-devel package is chosen initially but it
is subsequently replaced following a "reduced installs : 
selinux-policy-devel.noarch 0:2.3.7-2.fc5" message by the selinux-policy package
from the core repository.

I suspect that a significant factor in this problem is that during the course of
FC5's lifetime, the selinux-policy-devel package was split out from the main
selinux-policy package (this was the structure used in FC6, so it made sense to
do the split for reasons of consistency). So the FC5 core repo contains an
selinux-policy package containing all of the same files that are in the
selinux-policy-devel package in the FC5 updates repo, though there is no
"Provides: selinux-policy-devel".

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

How reproducible:
Every time.

Steps to Reproduce:
Try building the mod_fcgid package for Fedora 5 Extras using mock hosted on
Fedora Core 6.
  
Actual results:
Build fails due to required package not being present in buildroot.

Expected results:
Build succeeds, just as it did on an FC5 build host.

Additional info:
I shall attach some mock root.log files with yum running at debug level 7 to
illustrate the problem.
I have successfully worked around this problem by adding the line:

exclude=selinux-policy

to the [core] repo definition for FC5 in my mock configuration. With the option
of installing the old selinux-policy package from the core repo gone, yum
successfully installs the selinux-policy-devel package from the updates repo.

Comment 1 Paul Howarth 2006-10-31 15:11:52 UTC
Created attachment 139859 [details]
mock root.log with yum-3.0-6

This is the root.log from an attempted build of mod_fcgid using yum 3.0-6 with
my regular mock configuration and debugging at level 7. Some useful trace
information is missing because of tracebacks caused by Bug #212850.

Comment 2 Paul Howarth 2006-10-31 15:15:00 UTC
Created attachment 139860 [details]
mock root.log with modified yum-3.0-6

This is the root.log from an attempted build of mod_fcgid using a modified
version of yum 3.0-6 to fix the tracebacks mentioned in Bug #212850, with
my regular mock configuration and debugging at level 7. This log shows the late
decision to replace selinux-policy-devel (from updates) by selinux-policy (from
core).

Comment 3 Paul Howarth 2006-10-31 15:18:48 UTC
Created attachment 139861 [details]
mock root.log with modified yum-3.0-6 and explicit exclusion of selinux-policy from core repo

This is the root.log from a successful build of mod_fcgid using the modified
version of yum 3.0-6 to fix the tracebacks mentioned in Bug #212850, with
a modified mock configuration excluding the selinux-policy package from the
core repo, and debugging at level 7.

Comment 4 Jeremy Katz 2006-11-03 18:46:38 UTC
This is because the selinux-policy package from FC5 has an unversioned obsolete
of selinux-policy-devel.

Not sure why you're not picking up the newer (and in fc5-updates) selinux-policy
package, though...

Comment 5 Paul Howarth 2006-11-07 12:54:48 UTC
OK, the evil unversioned obsolete partly explains the behaviour them. I note
though that the Core FC5 doesn't have a provide to go with that obsolete.

So what I think intuitively should happen is that the request for
selinux-policy-devel should result in the package of that name from the updates
repo being installed. Now yum may realise that on its next run it could replace
that selinux-policy-devel with selinux-policy from FC5 core because of the
unversioned obsolete, and hence install that instead. However, following that
same argument, the selinux-policy package from updates should be installed
instead because that one naturally replaces the package from the core repo (as
you mentioned). The key difference here I think is that the package in updates
doesn't have the obsolete.

How about obsoletes only being checked in the latest available package of each
name from the selected repos? Would this cause any problems?


Comment 6 Till Maas 2006-11-30 00:35:01 UTC
> How about obsoletes only being checked in the latest available package of each
> name from the selected repos? Would this cause any problems?

I think this is an important feature to make sure that packaging mistakes can be
fixed within a release. This actual beheaviour of yum also causes problems when
an old packages obsolutes foo because a project was renamed from "foo" to "bar"
and there is another, completely different project with name "foo", too. This
happended lately with track (foo := track)



Comment 7 Jeremy Katz 2007-04-25 18:43:13 UTC
Is this better in the yum in the devel tree? (I think it _shoudl_ be)

Comment 8 Seth Vidal 2007-08-03 20:18:05 UTC
closing due to no response

Comment 9 Paul Howarth 2007-08-03 21:06:27 UTC
I must have missed the NEEDINFO somehow.

FWIW, this problem is no longer present in yum 3.2.2-1.fc7