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.
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.
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).
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.
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...
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?
> 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)
Is this better in the yum in the devel tree? (I think it _shoudl_ be)
closing due to no response
I must have missed the NEEDINFO somehow. FWIW, this problem is no longer present in yum 3.2.2-1.fc7