hi,
rhn-applet does not list glibc for update
# rpm -q rhn-applet rhn-applet-2.1.4-2
# rpm -qa | grep glibc glibc-kernheaders-2.4-8.36 glibc-headers-2.3.2-101 glibc-2.3.2-101 glibc-common-2.3.2-101 glibc-devel-2.3.2-101
rhn-applet-tui & rhn-applet-gui: Name Version Release ----------------------------------------------------------------------------- glibc-headers 2.3.2 101.1 glibc-devel 2.3.2 101.1 glibc-common 2.3.2 101.1
up2date --list Name Version Rel ---------------------------------------------------------- glibc 2.3.2 101.1 i686
glibc-common 2.3.2 101.1 i386
glibc-devel 2.3.2 101.1 i386
glibc-headers 2.3.2 101.1 i386
yum check-update Server: Fedora Core 1 - i386 - Released Updates Finding updated packages Downloading needed headers Name Arch Version Repo -------------------------------------------------------------------------------- glibc i686 2.3.2-101.1 updates-released glibc-common i386 2.3.2-101.1 updates-released glibc-devel i386 2.3.2-101.1 updates-released glibc-headers i386 2.3.2-101.1 updates-released
On Wed, Nov 19, 2003 at 09:30:34PM +0100, shrek-m@gmx.de wrote:
shrek-m@gmx.de wrote:
rhn-applet does not list glibc for update
happened only on this system (perhaps only on this fedora-installation) nforce1, athlon xp1800+ not on other sytems i had tested.
sorry
No problem, this can be explained by the following code extract from the YUM support of rhn-applet:
def __check_architecture(self, n, a): score = rpm.archscore(a) if score <= 0: return 0 if n == 'kernel' or n == 'kernel-smp' or n == 'kernel-uml' or \ n == 'kernel-unsupported' or n == 'glibc': if score != 1: return 0 return 1
Basically I don't want to misinstall a glibc compiled for i386 on an i686, rpm.archscore() returning 1 means that it's the closest architecture matching possible, i386 won't match on an i686, but also i686 won't match on an athlon ... That's where some distro specific informations starts hitting package dependancy resolvers and in a limited way the applet... Please bugzilla this, I will need to get this fixed the proper way, somehow I'm afraid that this can become messy on x86_64 for example.
Daniel