From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Hotbar
220.127.116.11; FunWebProducts; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Description of problem:
On this newly installed RHEL 3 (Red Hat 3.2.3-26 and 2.4.21-9.ELsmp)
system, up2date falls over, even with -f and -u options.
Test install failed because of package conflicts:
The following packages were added to your selection to satisfy
atk 1.2.4 3.0
glib2 2.2.3 2.0
gtk2 2.2.4 4.0
laus-libs 0.1 56RHEL3
laus-libs 0.1 56RHEL3
mozilla-nspr 1.4.2 3.0.2
mozilla-nss 1.4.2 3.0.2
pango 1.2.5 2.0
file /etc/pango/pango.modules from install of pango-1.2.5-2.0
conflicts with file from package pango-1.2.5-2.0
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. up2date -u -f
Actual Results: up2date aborted itself.
Expected Results: up2date to complete updates on all components.
Is there any update on this call please?
It's a known issue that not all libraries parallel install between
x86_64 and i386 in RHEL3. Work has been done to fix this in develment
versions but the changes are quite substantial and thus potentially
dangerous. It is not yet decided when to introduce those changes into
a RHEL3 update.
I'm going to reassing this bug to up2date since it isn't clear
to me why up2date should be trying to pull in the i386 version
of additional packages. There may be some debug options you can
add to get more information about why it's pulling in the above
I am seeing this on fedora core 3 test 1. To reproduce, install it on
an x86_64 machine fresh as a "workstation" install. Then run up2date
from the gnome "tray". When it displays the list of packages, you'll
see some i386 packages in there that duplicate the x86_64 ones that are
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.