Description of problem: up2date ignores multilib packages when using a local "dir" directory. Version: up2date-4.2.57-2 To reproduce: edit /e/s/r/sources and disable the default repo, and point up2date to the local repo: dir latest /opt/ia64-AS/ Note that ia64 and i386 versions of glibc are currently installed: # rpm -q glibc glibc-2.3.2-95.33.i686 glibc-2.3.2-95.33.ia64 Updated versions of both packages are present in my local repository: ls /opt/ia64-AS/glibc-2* /opt/ia64-AS/glibc-2.3.2-95.36.i686.rpm /opt/ia64-AS/glibc-2.3.2-95.36.ia64.rpm But up2date only sees the ia64 package: # up2date-nox -u --dry-run glibc Fetching Obsoletes list for channel: U6-nightly... Fetching rpm headers... ######################################## Name Version Rel ---------------------------------------------------------- glibc 2.3.2 95.36 ia64 Testing package set / solving RPM inter-dependencies... Downloading headers to solve dependencies... ####################################### Downloading headers to solve dependencies... There was a package dependency problem. The message was: Unresolvable chain of dependencies: glibc-2.3.2-95.33 requires glibc-common = 2.3.2-95.33 The following packages were added to your selection to satisfy dependencies: Package Required by ---------------------------------------------------------------------------- #
Blocking rhnupr4u4 and rhnupr3u8 to track the progress of the release
Moving bugs to the CanFix List
This looks ugly. Looks like it's borking because on ia64, rpm.archscore('i386') == 0, aka it's not compatible. Therefore, up2date just chucks it out the window as an option. Digging deeper, looks like we're getting around this by use of a compatibility table server-side. Problem is, there's no server to get around the lack of an i386 arch_compat macro when you're using a dirRepo.
So, after talking more w/ alikins, I'm probably on crack... archscore isn't always 0, depending upon hardware rev and/or emulation software. Do you have a system handy where archscore(i386) != 0 and it's still not seeing the i386?
This bug did not make the code freeze and it will not be fiixed during this release cycle. Re-aligning bug to the next release
This bug did not make the code freeze. It will not be fixed in this releasee Reea ligning to the next one.
*** Bug 191503 has been marked as a duplicate of this bug. ***
Fixed in up2date-4.5.0-1
*** Bug 199689 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0250.html
Workaround is to use yum instead of up2date. Use createrepo to create yum repository meta information. Then add the directory containing new packages under /etc/yum.repos.d/ It was working for me on RHEL 3.8 where up2date was not working.