These forums are read-only!
Why does CentOS yum pull both x86_64 and i386 on slice?
  • Hi there - subject says it all really:

    =============================================================================
    Package Arch Version Repository Size
    =============================================================================
    Installing:
    openssl-devel x86_64 0.9.8b-10.el5 base 1.8 M
    openssl-devel i386 0.9.8b-10.el5 base 1.8 M

    Is that necessary? How do I stop it if not?

    Cheers,
    Igor
  • You can throw this into /etc/yum.conf

    @exclude=*.i386 *.i586 *.i686@
    I believe if you still have .i386 packages installed, they won't be updated after adding that exclude line, so it might be good to uninstall them if you don't plan on using them.
  • Thanks!
  • Hi,

    I have updated the CentOS images we have and the default yum.conf now includes the exclude line.

    Always feel free to let us know of small (and large!) issues like that. We are very open to improving what we offer.

    PickledOnion
  • Hey, that's great, thanks!
  • Posted By: PickledOnionHi,

    I have updated the CentOS images we have and the default yum.conf now includes the exclude line.

    Always feel free to let us know of small (and large!) issues like that. We are very open to improving what we offer.

    PickledOnionDon't forget to checkout theSlicehost articles


    Hmm...do the CentOS images still contain a handful of i386 packages?
  • bq. ??ilikepi?? Hmm...do the CentOS images still contain a handful of i386 packages?

    They do...from a brand new slice:

    @curl.i386
    curl.x86_64
    device-mapper.i386
    device-mapper.x86_64
    e2fsprogs-libs.i386
    e2fsprogs-libs.x86_64
    glibc.i686
    glibc.x86_64
    keyutils-libs.i386
    keyutils-libs.x86_64
    krb5-libs.i386
    krb5-libs.x86_64
    libgcc.i386
    libgcc.x86_64
    libhugetlbfs.i386
    libhugetlbfs.x86_64
    libidn.i386
    libidn.x86_64
    libselinux.i386
    libselinux.x86_64
    libsepol.i386
    libsepol.x86_64
    libtermcap.i386
    libtermcap.x86_64
    mkinitrd.i386
    mkinitrd.x86_64
    openssl.i686
    openssl.x86_64
    readline.i386
    readline.x86_64
    zlib.i386
    zlib.x86_64
    @
    Hopefully removing all of these won't break anything...
  • Can you confirm removing the old 32bit packages does not break anything?

    How do you do it?
  • Everything seems OK. I ran the following:

    @# yum remove e2fsprogs-libs.i386 openssl.i686 mkinitrd.i386 device-mapper.i386 curl.i386
    keyutils-libs.i386 readline.i386 zlib.i386 krb5-libs.i386 device-mapper.i386
    libtermcap.i386 libsepol.i386 libselinux.i386 libidn.i386 libhugetlbfs.i386 libgcc.i386
    glibc.i686@
  • Bear in mind, of course, that if you have additional 32-bit packages, yum may complain about dependencies breaking by running that exact command. You would probably want to list all of the 32-bit packages you have.
  • It looks like the CentOS 5.3 image contains 53 32-bit packages (quite a bit more than on the 5.2 image), as well as a fair number of packages related to X11. A total of 342 packages are installed by default, compared to around 200 for the CentOS 5.2 image last time I built a new slice with it.

    It appears many of the extra packages are installed as dependencies for a package called paps (http://paps.sourceforge.net/). This is a program that converts UTF-8 text files to Postscript, and it makes use of the pango library. Pango has a number of X11-related dependencies. Paps does not appear to be required by any other package, so I'm not sure why it's installed by default.

    Also noteworthy, earlier in this thread it was mentioned that an exclude directive had been added to /etc/yum.conf in the CentOS image to reject 32-bit packages. This change seems to be absent from the 5.3 image.

    I know CentOS is not as popular as Ubuntu, but it would be cool if the default image could be stripped down a bit more.
  • In case anyone is or becomes curious, here are the results of my own cleanup efforts.

    I removed all 32-bit packages:
    # yum erase audit-libs.i386 cracklib.i386 cryptsetup-luks.i386 cyrus-sasl-lib.i386
    cyrus-sasl-plain.i386 db4.i386 device-mapper.i386 e2fsprogs-libs.i386 ecryptfs-utils.i386
    expat.i386 fipscheck.i386 glibc.i686 keyutils-libs.i386 krb5-libs.i386 libICE.i386
    libSM.i386 libX11.i386 libXau.i386 libXdmcp.i386 libXext.i386 libXi.i386 libXt.i386
    libXxf86vm.i386 libaio.i386 libdrm.i386 libgcc.i386 libgcrypt.i386 libgpg-error.i386
    libhugetlbfs.i386 libselinux.i386 libsepol.i386 libstdc++.i386 libtermcap.i386
    libutempter.i386 mesa-libGL.i386 ncurses.i386 nspr.i386 nss.i386 nss_db.i386
    nss_ldap.i386 numactl.i386 openldap.i386 openssl.i686 pam.i386 pam_ccreds.i386
    pam_krb5.i386 pam_passwdqc.i386 pam_pkcs11.i386 pam_smb.i386 parted.i386
    readline.i386 tcp_wrappers.i386 zlib.i386

    I removed all the stuff I considered unnecessary:
    # yum erase acl acpid amtu anacron attr autofs bc cairo conman cups-libs cyrus-sasl
    cyrus-sasl-plain dbus-python desktop-file-utils dhclient dhcpv6-client dosfstools dump
    ecryptfs-utils finger fipscheck fontconfig freetype gamin gamin-python gettext hesiod
    htmlview iptables-ipv6 jwhois krb5-workstation ksh kudzu lftp libaio libdaemon libdrm
    libICE libSM libtiff libutempter libX11 libXau libXdmcp libXext libXft libXi libXrender libXt
    libXxf86vm logwatch m4 mesa-libGL mgetty microcode_ctl mlocate mtools mtr nc nscd
    nss_db nss_ldap nss-tools ntsysv numactl oddjob oddjob-libs pam_ccreds pam_krb5
    pam_passwdqc pam_pkcs11 pam_smb pango paps parted patch pax perl-String-CRC32
    pinfo pkinit-nss portmap procmail psacct pygobject2 quota rdate rdist redhat-menus
    rhpl rmt rng-utils rsh setarch setserial sos specspo stunnel symlinks syslinux
    system-config-network-tui system-config-securitylevel-tui talk tcsh tmpwatch tree
    udftools wireless-tools xorg-x11-filesystem ypbind yp-tools yum-updatesd

    (Yum messed up the order of redhat-menus and desktop-file-utils, so redhat-menus failed to uninstall. I had to reinstall desktop-file-utils, uninstall redhat-menus, then uninstall desktop-file-utils. Not sure if this was a fluke or what....)

    Here's a list of packages which I believe were not in the 5.2 image, but that I chose to keep. Most of these I would have installed manually anyway:
    at
    audit
    authconfig
    bind-libs
    bind-utils
    binutils
    crash
    ftp
    gnupg
    ipsec-tools
    iptables
    irqbalance
    lsof
    mailx
    make
    man-pages
    readahead
    rsync
    setuptool
    tcpdump
    telnet
    time
    traceroute
    unzip
    which
    words
    zip

    To help with figuring out what I could get rid of, I generated something resembling a two-level dependency tree using the following one-liner (apologies for the lack of wrapping; the formatted output does not play well with copy and paste):
    for p in `rpm -qa --queryformat '%{NAME}\n' | sort`; do echo $p; rpm -q --whatrequires --queryformat '    %{NAME}\n' `rpm -q --provides $p | cut -f1 -d' '` | grep -v "^no package requires\|^    ${p}$" | sort -u; done

    Here's a snippet of the output:
    basesystem
    glibc
    bash
    info
    initscripts
    sysklogd
    vixie-cron
    ypbind
    bc
    bind-libs
    bind-utils
    bind-utils
    binutils
    crash
    bzip2
    man

    So for each package p, list (indented) all installed packages that depend on p.

    Hope this is helpful to someone...

    edit: fixed stupid formatting bug which caused Preview output to differ from actual output
  • Heya,

    I have spoken to the image maintainers and asked them to take a look at it. Once they have taken action they will be able to update this thread.

    Thanks for the details.

    PickledOnion
  • Cool, thanks.:)
  • Seems there are some glibc packages which have 32-bit dependencies as well - I tried yum install gcc gcc-c++ on a fresh slice and had problems, so I just removed the exclude= line from /etc/yum.conf while installing those, then put it back in afterwards.

    Interestingly quite a few packages when built from source have problems with /usr/lib vs /usr/lib64 - I've just been symlinking the /usr/lib64 .so files into /usr/lib as necessary, but it would be nice not to have to. I guess a lot of the time it's because the packages are hard-coded to expect /usr/lib - though I guess if we're going to ditch that for /usr/lib64 we ought to handle it?

    Cheers
    i
  • When I run 'yum install gcc gcc-c++' on my newly cleaned slice, all the dependencies listed are 64-bit. What sort of problems did you have?

    It's surprising to hear of software having trouble with /usr/lib versus /usr/lib64.
  • I got the same prob, I want to confirm one thing, if you are using vmware?
  • I got the answer,
    http://wiki.centos.org/FAQ/General#head-357346ff0bf7c14b0849c3bcce39677aaca528e9