Hi,
what is supposed to go into /usr/local/lib/ and what into /usr/local/lib64 on amd64?
I'm trying to get libsx installed and am wondering into which of these directories it is supposed to go. /usr/local/lib/ sounds like "native", but then there wouldn't be /usr/local/lib64/, or would there?
Am 20.07.2013 20:02, schrieb lee:
what is supposed to go into /usr/local/lib/ and what into /usr/local/lib64 on amd64?
I'm trying to get libsx installed and am wondering into which of these directories it is supposed to go. /usr/local/lib/ sounds like "native", but then there wouldn't be /usr/local/lib64/, or would there?
/usr/local is more or less the same as /usr
/usr/local/lib -> i686 libraries /usr/local/lib64 -> x86_64 libraries
https://ask.fedoraproject.org/question/7916/multilib-packaging-policy/ http://www.tuxfiles.org/linuxhelp/linuxdir.html
Reindl Harald h.reindl@thelounge.net writes:
Am 20.07.2013 20:02, schrieb lee:
what is supposed to go into /usr/local/lib/ and what into /usr/local/lib64 on amd64?
I'm trying to get libsx installed and am wondering into which of these directories it is supposed to go. /usr/local/lib/ sounds like "native", but then there wouldn't be /usr/local/lib64/, or would there?
/usr/local is more or less the same as /usr
/usr/local/lib -> i686 libraries /usr/local/lib64 -> x86_64 libraries
https://ask.fedoraproject.org/question/7916/multilib-packaging-policy/ http://www.tuxfiles.org/linuxhelp/linuxdir.html
Thanks! I just put stuff that I install myself into /usr/local ...
Any idea as to why there are so many 32bit libs installed I don't need?
Am 21.07.2013 10:46, schrieb lee:
Reindl Harald h.reindl@thelounge.net writes:
Am 20.07.2013 20:02, schrieb lee:
what is supposed to go into /usr/local/lib/ and what into /usr/local/lib64 on amd64?
I'm trying to get libsx installed and am wondering into which of these directories it is supposed to go. /usr/local/lib/ sounds like "native", but then there wouldn't be /usr/local/lib64/, or would there?
/usr/local is more or less the same as /usr
/usr/local/lib -> i686 libraries /usr/local/lib64 -> x86_64 libraries
https://ask.fedoraproject.org/question/7916/multilib-packaging-policy/ http://www.tuxfiles.org/linuxhelp/linuxdir.html
Thanks! I just put stuff that I install myself into /usr/local ... Any idea as to why there are so many 32bit libs installed I don't need?
no, but "yum remove *i686*" should kill them :-)
[root@srv-rhsoft:~]$ rpm -qa | grep i686 | wc -l 0
[root@srv-rhsoft:~]$ rpm -qa | grep x86_64 | wc -l 1081
[root@srv-rhsoft:~]$ rpm -qa | grep noarch | wc -l 235 ____________________________________________________________
exclude=*.i686 in the .repo-files in /etc/yum/.repos.d/ prevents to get one installed even with maximum wired dependencies (packaging errors)
<snip>
Any idea as to why there are so many 32bit libs installed I don't need?
no, but "yum remove *i686*" should kill them :-)
[root@srv-rhsoft:~]$ rpm -qa | grep i686 | wc -l 0
[root@srv-rhsoft:~]$ rpm -qa | grep x86_64 | wc -l 1081
[root@srv-rhsoft:~]$ rpm -qa | grep noarch | wc -l 235 ____________________________________________________________
exclude=*.i686 in the .repo-files in /etc/yum/.repos.d/ prevents to get one installed even with maximum wired dependencies (packaging errors)
For a long time wine needed the 32 bit libs, as did Adobe Reader (they may still, I don't know as I don't use them at all these days). If you have either of those installed it may be why you still have the 32 bit libs installed.
Kevin
Am 22.07.2013 00:27, schrieb Kevin Martin:
For a long time wine needed the 32 bit libs, as did Adobe Reader (they may still, I don't know as I don't use them at all these days). If you have either of those installed it may be why you still have the 32 bit libs installed
wine, AdobeReader as well as Skype are *pure* 32bit apps
On 07/21/2013 06:30 PM, Reindl Harald wrote:
Am 22.07.2013 00:27, schrieb Kevin Martin:
For a long time wine needed the 32 bit libs, as did Adobe Reader (they may still, I don't know as I don't use them at all these days). If you have either of those installed it may be why you still have the 32 bit libs installed
wine, AdobeReader as well as Skype are *pure* 32bit apps
On my In the 64-bit PCLOS repos there is Wine64. I don't know any more than that, but that's what it's called. On the same system, there is no AdobeReader, and I sure wish I knew how to get it to work!
--doug
Am 23.07.2013 22:16, schrieb doug:
On 07/21/2013 06:30 PM, Reindl Harald wrote:
Am 22.07.2013 00:27, schrieb Kevin Martin:
For a long time wine needed the 32 bit libs, as did Adobe Reader (they may still, I don't know as I don't use them at all these days). If you have either of those installed it may be why you still have the 32 bit libs installed
wine, AdobeReader as well as Skype are *pure* 32bit apps
On my In the 64-bit PCLOS repos there is Wine64
well, and wine-x84_64 is for *64 bit windows applications*
I don't know any more than that, but that's what it's called.
you could do google "wine64" as i did for you
http://wiki.winehq.org/Wine64 This page is for notes on the 64-bit port of Wine for AMD64 (a.k.a. x64 or x86-64)
Reindl Harald h.reindl@thelounge.net writes:
Am 21.07.2013 10:46, schrieb lee:
Reindl Harald h.reindl@thelounge.net writes:
Am 20.07.2013 20:02, schrieb lee:
what is supposed to go into /usr/local/lib/ and what into /usr/local/lib64 on amd64?
I'm trying to get libsx installed and am wondering into which of these directories it is supposed to go. /usr/local/lib/ sounds like "native", but then there wouldn't be /usr/local/lib64/, or would there?
/usr/local is more or less the same as /usr
/usr/local/lib -> i686 libraries /usr/local/lib64 -> x86_64 libraries
https://ask.fedoraproject.org/question/7916/multilib-packaging-policy/ http://www.tuxfiles.org/linuxhelp/linuxdir.html
Thanks! I just put stuff that I install myself into /usr/local ... Any idea as to why there are so many 32bit libs installed I don't need?
no, but "yum remove *i686*" should kill them :-)
So I have removed the i686 packages:
,---- | [root@yun:~]$ yum list installed |grep 686 | texlive-url.noarch 3:svn16864.3.2-0.1.fc19 installed | [root@yun:~]$ du -hs /usr/lib/ | 582M /usr/lib/ | [root@yun:~]$ find /usr/lib/ -type f | wc -l | 14060 | [root@yun:~]$ `----
/usr/lib/ should be empty now. Why is it not?
And why are the kernel modules not in /usr/lib64/modules/?
,---- | [root@yun:/usr/lib/modules/3.9.9-302.fc19.x86_64/kernel/fs]$ file binfmt_misc.ko | binfmt_misc.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), [...] | [root@yun:/usr/lib/modules/3.9.9-302.fc19.x86_64/kernel/fs]$ `----
Why is systemd not in /user/lib64/ on 64bit systems? What kind of mess is this? At least "find . -type f -executable -print0 | xargs -0 file |grep 'ELF 32'" shows that the only executables in 32bit are grub modules and kernel modules in ./modules/3.9.9-302.fc19.x86_64/vdso.
It seems as if they haven't been entirely successful with moving everything 64bit to /usr/lib64/. (I wonder anyway why it's not /usr/lib/ and /usr/lib32 ...)
This isn't compliant with the FHS[1], though Fedora claims they are using it[2]. For example, /usr/lib/systemd doesn't fullfill the requirements specified in the FHS[1].
,---- | [root@yun:/usr/lib]$ find -name 'libc.so.*' | wc -l | 0 | [root@yun:/usr/lib]$ find -name 'ld*' | wc -l | 10 | [root@yun:/usr/lib]$ `----
So only 10 of over 14000 files in /usr/lib fullfill the requirements for /usr/lib.
[1]: http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBESSENTIALSHAREDLIBRARIESANDK... [2]: http://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Gu...
exclude=*.i686 in the .repo-files in /etc/yum/.repos.d/ prevents to get one installed even with maximum wired dependencies (packaging errors)
Cool, I've added that, too.
Am 22.07.2013 13:41, schrieb lee:
Reindl Harald h.reindl@thelounge.net writes:
no, but "yum remove *i686*" should kill them :-)
So I have removed the i686 packages:
| [root@yun:~]$ yum list installed |grep 686 | texlive-url.noarch 3:svn16864.3.2-0.1.fc19 installed | [root@yun:~]$ du -hs /usr/lib/ | 582M /usr/lib/ | [root@yun:~]$ find /usr/lib/ -type f | wc -l | 14060 | [root@yun:~]$ `---- /usr/lib/ should be empty now. Why is it not?
says who?
http://www.pathname.com/fhs/pub/fhs-2.3.html /lib : Essential shared libraries and kernel modules
http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE11 http://www.pathname.com/fhs/pub/fhs-2.3.html#REQUIREMENTS5 http://www.pathname.com/fhs/pub/fhs-2.3.html#SPECIFICOPTIONS7
And why are the kernel modules not in /usr/lib64/modules/?
because the FHS says it and after UsrMove anything in /lib was merged to /usr/lib
lrwxrwxrwx 1 root root 7 2013-05-30 23:36 bin -> usr/bin lrwxrwxrwx 1 root root 7 2013-05-30 23:36 lib -> usr/lib lrwxrwxrwx 1 root root 9 2013-05-30 23:36 lib64 -> usr/lib64 lrwxrwxrwx 1 root root 8 2013-05-30 23:36 sbin -> usr/sbin
Reindl Harald h.reindl@thelounge.net writes:
Am 22.07.2013 13:41, schrieb lee:
Reindl Harald h.reindl@thelounge.net writes:
no, but "yum remove *i686*" should kill them :-)
So I have removed the i686 packages:
| [root@yun:~]$ yum list installed |grep 686 | texlive-url.noarch 3:svn16864.3.2-0.1.fc19 installed | [root@yun:~]$ du -hs /usr/lib/ | 582M /usr/lib/ | [root@yun:~]$ find /usr/lib/ -type f | wc -l | 14060 | [root@yun:~]$ `---- /usr/lib/ should be empty now. Why is it not?
says who?
Since libraries are supposed to be in /usr/lib64 on 64bit systems and the packages that provide 32bit software are removed, there aren't any libraries left to go into /usr/lib.
http://www.pathname.com/fhs/pub/fhs-2.3.html /lib : Essential shared libraries and kernel modules
http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE11 http://www.pathname.com/fhs/pub/fhs-2.3.html#REQUIREMENTS5
As I said, only 10 of over 14000 files in /usr/lib fullfill these requirements.
http://www.pathname.com/fhs/pub/fhs-2.3.html#SPECIFICOPTIONS7
And why are the kernel modules not in /usr/lib64/modules/?
Well ok, kernel modules aren't libraries.
because the FHS says it and after UsrMove anything in /lib was merged to /usr/lib
lrwxrwxrwx 1 root root 7 2013-05-30 23:36 bin -> usr/bin lrwxrwxrwx 1 root root 7 2013-05-30 23:36 lib -> usr/lib lrwxrwxrwx 1 root root 9 2013-05-30 23:36 lib64 -> usr/lib64 lrwxrwxrwx 1 root root 8 2013-05-30 23:36 sbin -> usr/sbin
That was a very bad idea:
"/bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted"[1]
The /usr file system is usually on its own partition. Implicitly creating a requirement to have it on the same partition as the root fs is bad, and /bin should not be under /usr. It violates the FHS, see [2]: /usr/bin should hold "most user commands", and considering [1], that excludes commands "which are required when no other filesystems are mounted" unless you want dupes.
[1]: http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES [2]: http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
On Mon, 22 Jul 2013 14:31:11 +0200, lee wrote:
/usr/lib/ should be empty now. Why is it not?
says who?
Since libraries are supposed to be in /usr/lib64 on 64bit systems and the packages that provide 32bit software are removed, there aren't any libraries left to go into /usr/lib.
It isn't difficult to browse /usr/lib a bit and notice what files are stored in that directory. It's not just for 32-bit libs as has been shown earlier in this thread.
Michael Schwendt mschwendt@gmail.com writes:
On Mon, 22 Jul 2013 14:31:11 +0200, lee wrote:
/usr/lib/ should be empty now. Why is it not?
says who?
Since libraries are supposed to be in /usr/lib64 on 64bit systems and the packages that provide 32bit software are removed, there aren't any libraries left to go into /usr/lib.
It isn't difficult to browse /usr/lib a bit and notice what files are stored in that directory. It's not just for 32-bit libs as has been shown earlier in this thread.
Yes, and when you look at what the FHS requires for files in /usr/lib/, you can see that it says those files shouldn't be there:
,---- | At least one of each of the following filename patterns are required | (they may be files, or symbolic links): | | File Description | libc.so.* The dynamically-linked C library (optional) | ld* The execution time linker/loader (optional) `---- [1]
Only 10 of over 14000 files in there match the requirement. The FHS speaks at [2] explicitly of "shared library images needed to boot the system and run the commands in the root filesystem". It doesn't seem to explicitly define what is to be considered as "shared library", yet [1] indicates that it refers to binary files which are dynamically linked when programs are being run that require them.
Therefore, a file like /usr/lib/systemd/system/dbus.service must not exist, like many others. It is not a shared library, and it does not meet the requirements for file name patterns. (I would consider it as a configuration file which should go unter /etc. No wonder that I can't get used to where they put the files in Fedora ...)
[1]: http://www.pathname.com/fhs/pub/fhs-2.3.html#REQUIREMENTS5 [2]: http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE11
Am 22.07.2013 14:31, schrieb lee:
Reindl Harald h.reindl@thelounge.net writes:
because the FHS says it and after UsrMove anything in /lib was merged to /usr/lib
lrwxrwxrwx 1 root root 7 2013-05-30 23:36 bin -> usr/bin lrwxrwxrwx 1 root root 7 2013-05-30 23:36 lib -> usr/lib lrwxrwxrwx 1 root root 9 2013-05-30 23:36 lib64 -> usr/lib64 lrwxrwxrwx 1 root root 8 2013-05-30 23:36 sbin -> usr/sbin
That was a very bad idea:
"/bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted"[1]
lsinitrd | grep usr/bin lsinitrd | grep usr/sbin
The /usr file system is usually on its own partition. Implicitly creating a requirement to have it on the same partition as the root fs is bad, and /bin should not be under /usr. It violates the FHS, see [2]: /usr/bin should hold "most user commands", and considering [1], that excludes commands "which are required when no other filesystems are mounted" unless you want dupes.
On 07/21/13 02:02, lee wrote:
Hi,
what is supposed to go into /usr/local/lib/ and what into /usr/local/lib64 on amd64?
I'm trying to get libsx installed and am wondering into which of these directories it is supposed to go. /usr/local/lib/ sounds like "native", but then there wouldn't be /usr/local/lib64/, or would there?
Well, if you're building the 32-bit lib it would go in /usr/local/lib/ or if you're building the 64-bit lib it would go in /usr/local/lib64
Example....
[egreshko@meimei lib64]$ rpm -qa | grep libthai libthai-0.1.14-6.fc18.x86_64 libthai-0.1.14-6.fc18.i686
[egreshko@meimei /]$ file lib/libthai.so.0.1.6 lib/libthai.so.0.1.6: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x8b3b836abc76ff27cbc72ddf05e31b4eec431b26, stripped [egreshko@meimei /]$ file lib64/libthai.so.0.1.6 lib64/libthai.so.0.1.6: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x5c24ffeb8fe5136970c1b1f42ef2bd9ce3ede746, stripped
Ed Greshko Ed.Greshko@greshko.com writes:
On 07/21/13 02:02, lee wrote:
Hi,
what is supposed to go into /usr/local/lib/ and what into /usr/local/lib64 on amd64?
I'm trying to get libsx installed and am wondering into which of these directories it is supposed to go. /usr/local/lib/ sounds like "native", but then there wouldn't be /usr/local/lib64/, or would there?
Well, if you're building the 32-bit lib it would go in /usr/local/lib/ or if you're building the 64-bit lib it would go in /usr/local/lib64
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:~]$
/usr/lib/ should be empty. Why are there so many obsolete files installed?
BTW, why are there so many i686 packages installed:
[root@yun:~]$ yum list installed |grep 686 audit-libs.i686 2.3.1-2.fc19 installed cracklib.i686 2.8.22-3.fc19 installed dbus-libs.i686 1:1.6.12-1.fc19 installed gamin.i686 0.1.10-14.fc19 installed glib2.i686 2.36.3-2.fc19 installed glibc.i686 2.17-11.fc19 installed libX11.i686 1.6.0-1.fc19 installed libXau.i686 1.0.8-1.fc19 installed libattr.i686 2.4.46-10.fc19 installed libcap.i686 2.22-6.fc19 installed libdb.i686 5.3.21-11.fc19 installed libdrm.i686 2.4.46-1.fc19 installed libffi.i686 3.0.13-4.fc19 installed libgcc.i686 4.8.1-1.fc19 installed libgcrypt.i686 1.5.2-1.fc19 installed libgpg-error.i686 1.11-1.fc19 installed libpciaccess.i686 0.13.1-3.fc19 installed libselinux.i686 2.1.13-15.fc19 installed libstdc++.i686 4.8.1-1.fc19 installed libuuid.i686 2.23.1-3.fc19 installed libwayland-client.i686 1.1.90-0.1.20130515.fc19 installed libwayland-server.i686 1.1.90-0.1.20130515.fc19 installed libxcb.i686 1.9-3.fc19 installed mesa-libEGL.i686 9.2-0.12.20130610.fc19 installed mesa-libEGL-devel.i686 9.2-0.12.20130610.fc19 installed mesa-libgbm.i686 9.2-0.12.20130610.fc19 installed mesa-libglapi.i686 9.2-0.12.20130610.fc19 installed ncurses-libs.i686 5.9-11.20130511.fc19 installed nss-softokn-freebl.i686 3.15.1-1.fc19 @updates pam.i686 1.1.6-12.fc19 @updates pcre.i686 8.32-7.fc19 installed pyzy.i686 0.1.0-6.fc19 installed readline.i686 6.2-6.fc19 installed sqlite.i686 3.7.17-1.fc19 installed systemd-libs.i686 204-9.fc19 installed texlive-url.noarch 3:svn16864.3.2-0.1.fc19 installed xz-libs.i686 5.1.2-4alpha.fc19 installed zlib.i686 1.2.7-10.fc19 installed [root@yun:~]$
Can I remove those? Are there amd64 packages depending on i686 packages?
On 07/21/13 16:13, lee wrote:
Ed Greshko Ed.Greshko@greshko.com writes:
On 07/21/13 02:02, lee wrote:
Hi,
what is supposed to go into /usr/local/lib/ and what into /usr/local/lib64 on amd64?
I'm trying to get libsx installed and am wondering into which of these directories it is supposed to go. /usr/local/lib/ sounds like "native", but then there wouldn't be /usr/local/lib64/, or would there?
Well, if you're building the 32-bit lib it would go in /usr/local/lib/ or if you're building the 64-bit lib it would go in /usr/local/lib64
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:~]$
/usr/lib/ should be empty. Why are there so many obsolete files installed?
BTW, why are there so many i686 packages installed:
[root@yun:~]$ yum list installed |grep 686 audit-libs.i686 2.3.1-2.fc19 installed cracklib.i686 2.8.22-3.fc19 installed
Can I remove those? Are there amd64 packages depending on i686 packages?
You can certainly try.....
If you do try and something depends on them, yum will let you know what needs them and will offer to erase them as well.... Then you can decide *if* you can/should remove them.
On Sun, 21 Jul 2013 10:13:03 +0200 lee lee@yun.yagibdah.de wrote:
BTW, why are there so many i686 packages installed:
I have noticed Fedora x86_64 tends to do that as long as I've been using Fedora. what I've resorted to in /etc/yum.conf is: exclude=*i386* *i486* *i586* *i686
It will complain if try you remove them, but it can be done slowly\carefully. using rpm -e --nodeps where appropriate (Use with Caution)
On Sun, 21 Jul 2013 10:59:21 +0100, Frank Murphy wrote:
On Sun, 21 Jul 2013 10:13:03 +0200 lee wrote:
BTW, why are there so many i686 packages installed:
I have noticed Fedora x86_64 tends to do that as long as I've been using Fedora. what I've resorted to in /etc/yum.conf is: exclude=*i386* *i486* *i586* *i686
It will complain if try you remove them, but it can be done slowly\carefully. using rpm -e --nodeps where appropriate (Use with Caution)
That is wrong advice. You don't need --nodeps to remove the 32-bit packages. You could do things similar to
rpm -qa|grep .i*86$|xargs rpm -e
to remove all of them at once without introducing broken dependencies.
# rpm -qa |grep -v noarch|grep -v _64|grep -v pubkey #
Am 21.07.2013 14:02, schrieb Michael Schwendt:
On Sun, 21 Jul 2013 10:59:21 +0100, Frank Murphy wrote:
On Sun, 21 Jul 2013 10:13:03 +0200 lee wrote:
BTW, why are there so many i686 packages installed:
I have noticed Fedora x86_64 tends to do that as long as I've been using Fedora. what I've resorted to in /etc/yum.conf is: exclude=*i386* *i486* *i586* *i686
It will complain if try you remove them, but it can be done slowly\carefully. using rpm -e --nodeps where appropriate (Use with Caution)
That is wrong advice
and a very dangerous
*never* type "--nodeps" at all as long you are not 100% sure what you are doing at the moment
You don't need --nodeps to remove the 32-bit packages
and not for anything else if you are not firm how to recover your system if there was a cross-dependency killing nss or similar mandatory libraries resulting in rpm, yum, sshd are dead and you are done until restore the library files per hand
been there with "rpm -e --nodeps nss-softokn" years ago to solve a different dependency problem
You could do things similar to rpm -qa|grep .i*86$|xargs rpm -e
ouch - why not "yum remove *.i686" instead bypass yum? been there, done that often before "exclude=*.i686"
On Sun, 21 Jul 2013 14:02:20 +0200 Michael Schwendt mschwendt@gmail.com wrote:
It will complain if try you remove them, but it can be done slowly\carefully. using rpm -e --nodeps where appropriate (Use with Caution)
That is wrong advice. You don't need --nodeps to remove the 32-bit packages. You could do things similar to
rpm -qa|grep .i*86$|xargs rpm -e
That's actually nice to know.
On 07/21/2013 02:02 PM, Michael Schwendt wrote:
That is wrong advice. You don't need --nodeps to remove the 32-bit packages. You could do things similar to
rpm -qa|grep .i*86$|xargs rpm -e
to remove all of them at once without introducing broken dependencies.
I would run a
yum remove glibc.i686
That one will easily tear down the entire 32 bit world. ;-)
Just be sure you do not have specific (proprietary?) 32 bit apps you want to keep.
On 07/21/13 22:51, Roberto Ragusa wrote:
On 07/21/2013 02:02 PM, Michael Schwendt wrote:
That is wrong advice. You don't need --nodeps to remove the 32-bit packages. You could do things similar to
rpm -qa|grep .i*86$|xargs rpm -e
to remove all of them at once without introducing broken dependencies.
I would run a
yum remove glibc.i686
That one will easily tear down the entire 32 bit world. ;-)
Just be sure you do not have specific (proprietary?) 32 bit apps you want to keep.
I really do wonder what all the fuss is about.
I run a 64 bit systems and have managed to accumulate some 32 bit libs along the way. OK, maybe it takes up just over 1GB of disk space but on a 750GB drive that is way less than 1%.
It isn't as if this is MS windows with dll's getting loaded into memory willy nilly.
Yes it may be just me....but micro managing this, to me, is more trouble than it is worth.
Ed Greshko Ed.Greshko@greshko.com writes:
On 07/21/13 22:51, Roberto Ragusa wrote:
On 07/21/2013 02:02 PM, Michael Schwendt wrote:
That is wrong advice. You don't need --nodeps to remove the 32-bit packages. You could do things similar to
rpm -qa|grep .i*86$|xargs rpm -e
to remove all of them at once without introducing broken dependencies.
I would run a
yum remove glibc.i686
That one will easily tear down the entire 32 bit world. ;-)
Just be sure you do not have specific (proprietary?) 32 bit apps you want to keep.
I really do wonder what all the fuss is about.
I run a 64 bit systems and have managed to accumulate some 32 bit libs along the way. OK, maybe it takes up just over 1GB of disk space but on a 750GB drive that is way less than 1%.
It isn't as if this is MS windows with dll's getting loaded into memory willy nilly.
Yes it may be just me....but micro managing this, to me, is more trouble than it is worth.
This isn't much about disk space, though not having to back up obsolete stuff, not needing to update or to upgrade it, not having possible security risks through it and restorecon not needing to adjust permissions on a few thousand files during upgrades is a benefit. There are probably some more advantages, too.
It's about knowing what's installed and going on with my system and about keeping it clean and the way I want it.
I installed a 64bit system, not a 32bit one. That these 32bit libs are installed seems to be a bug in the installer. I'll try to remove them and see what happens ...
On Sun, 21 Jul 2013 16:51:01 +0200, Roberto Ragusa wrote:
On 07/21/2013 02:02 PM, Michael Schwendt wrote:
That is wrong advice. You don't need --nodeps to remove the 32-bit packages. You could do things similar to
rpm -qa|grep .i*86$|xargs rpm -e
to remove all of them at once without introducing broken dependencies.
I would run a
yum remove glibc.i686
That one will easily tear down the entire 32 bit world. ;-)
That should work in many cases.
There can be arch-specific packages that don't depend on glibc, however, or some which don't implement a base package dependency. For example, -static library packages, C++ template-only API -devel packages.
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.