On Sun, 21 Jul 2013 10:13:03 +0200, lee wrote: > Thanks! I don't do 32bit anymore, so it's 64. > > Strange is: > > > [root@yun:~]$ find /usr/lib -type f | wc -l > 14490 > [root@yun:~]$ find /usr/lib64/ -type f | wc -l > 15345 > [root@yun:~]$ Not so strange, because /usr/lib does not imply "32-bit only". You would need to search for shared libs, for example: $ find /usr/lib -type f -name \*.so.\* -a ! -name \*.debug|wc -l 1 $ find /usr/lib64 -type f -name \*.so.\* -a ! -name \*.debug|wc -l 1120 # find /usr/lib -type f | wc -l 9790 > /usr/lib/ should be empty. Why are there so many obsolete files > installed? > > > BTW, why are there so many i686 packages installed: If you use Yum, examine the yum.log files (also the old ones). Perhaps take a look at "yum history". Sometimes a larger set of i686 packages gets installed when there are broken dependencies temporarily [1]. Running "yum -y update" may have added them without you getting a chance to say "no". [1] A typical scenario when that happens with x86_64 is: An update "takes away" something needed by an installed package. Normally, that update could not be installed, because there would be a broken dependency. If that dependency is "weak" (not arch-specific, just a package name, for example), Yum may find that an i686 package can be used to resolve the dependency. Unless multi-lib version protection kicks in, you would get i686 packages on x86_64. Then, when a later update fixes the broken dependencies, that's too late for you. Another common scenario is when arch-specific packages obsolete a ".noarch" package. Since ".noarch" is "any arch", Yum would install all availables builds for all compatible archs (.noarch -> .x86_64 + .i686) to properly replace the package. > [root@yun:~]$ yum list installed |grep 686 > audit-libs.i686 2.3.1-2.fc19 installed > cracklib.i686 2.8.22-3.fc19 installed > > pyzy.i686 0.1.0-6.fc19 installed > Can I remove those? Use "repoquery", try "yum remove ...", or even "rpm --test --erase …". Some experience will be needed, however. (Don't misuse "rpm -q --whatrequires …".) # repoquery --whatrequires pyzy.i686 pyzy-devel-0:0.1.0-6.fc19.i686 pyzy-devel-0:0.1.0-6.fc19.x86_64 Default option for repoquery is --alldeps, which includes package names, so pyzy-devel.x86_64 does _not_ require pyzy.i686, but just the "pyzy" package name: # repoquery --exactdeps --whatrequires pyzy.i686 # # repoquery --exactdeps --whatrequires pyzy pyzy-devel-0:0.1.0-6.fc19.i686 pyzy-devel-0:0.1.0-6.fc19.x86_64 That's a weak dependency as described above. The package ought to be updated to adhere to Fedora's Packaging Guidelines. # repoquery --whatrequires audit-libs.i686|grep -v x86_64 audit-libs-devel-0:2.3.1-2.fc19.i686 cups-libs-1:1.6.2-9.fc19.i686 cups-libs-1:1.6.3-1.fc19.i686 gdm-1:3.8.3-2.fc19.i686 libguestfs-1:1.22.2-1.fc19.i686 libguestfs-1:1.22.3-1.fc19.i686 libvirt-client-0:1.0.5.1-1.fc19.i686 libvirt-client-0:1.0.5.2-1.fc19.i686 pam-0:1.1.6-11.fc19.1.i686 pam-0:1.1.6-12.fc19.i686 > Are there amd64 packages depending on i686 packages? Yes, "wine" for example explicitly wants a 32-bit run-time. -- Michael Schwendt Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.9-302.fc19.x86_64 loadavg: 0.16 0.08 0.06 -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
