From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6 Description of problem: I do not think this is an rpm bug, but a problem in the packages it is upgrading. 1.) Got all updates in the i386 directory on 6/08/2003. 2.) Removed a couple duplicates, keeping the higher versions. 3.) Did rpm -F *.rpm 4.) Upgrade progressed. 5.) pre and post install scripts started reporting failure; segfault messages. 6.) after install completed (with lots of errors), most commands would not work - they segfaulted. 7.) Rebooted machine via big red button method as shutdown segfaulted 8.) Boot failed because mingetty et al. were segfaulting too 9.) Reloaded box. Repeated from step 1. Same thing happened. Version-Release number of selected component (if applicable): rpm-4.2-0.69 How reproducible: Always Steps to Reproduce: 1. Get the contents of the i386 dir on updates as of 6/8/03 2. rpm -F *.rpm 3. Watch your machine die pitifully. Actual Results: All newly executed programs segfaulted. Like: > ps Segmentation Fault > xterm Segementation Fault > shutdown -r now Segmentation Fault You get the idea. Expected Results: I should have gotten a process list, another xterm, and a message telling me that I can't reboot the machine because I'm not root, respectively. Additional info: This is a Very Bad Thing. Spending my evening reloading my box twice (once to try and reproduce, once to just have a working box) brings back all my bad memories of running Windows.
Duplicate of bug 88456 . Replacing an i686 glibc package with an i386 one is not a good idea.
Well than RedHat has suffered from a dumbass attack, and indeed, this is a problem with rpm in general. 1.) It is not known what architecture a package is compiled for once it is installed (the real bug that rpm should detect and complain about). Example: > rpm -qa | grep glibc glibc-devel-2.3.2-5 glibc-common-2.3.2-5 glibc-kernheaders-2.4-8.10 glibc-2.3.2-5 No information at all about target architecture. rpm should detect this and error out. 2.) replacing the i686 packages with the i386 packages SHOULD work, since anything that can run i686 code can run i386 code. Shouldn't both libraries export the same functions? If the app is statically linked, it doesn't care, and if it's dynamically linked, it should just get the new functions at runtime. 3.) I did not realize, and I wonder how many people actually do realize, that different packages are installed based on architecture. I assumed that with this release, like with the versions before it, everything was compiled for an i386. This was obviously incorrect. However, it's news to many people.
1. There are legitimate reasons to replace packages of one sub-architecture with one of another sub-architecture. Typically it doesn't cause things to blow up either. So, it shouldn't be impossible to do this, but I guess it should be harder (for example, an extra command line option, or a confirmation prompt of some kind). 2. The i686 glibc packages have NPTL support. NPTL requires glibc to be compiled for i486 or up, so it's omitted from the i386 glibc packages. IIRC the problem is that the glibc package was leaving some old files behind when upgrading i686->i386. AFAIK the glibc packages in Rawhide fix that problem. 3. Different packages have been installed, based on sub-architecture, since Red Hat 6.0. (In particular: the kernel in 6.0 and up, glibc in 7.0 and up, and openssl in 7.2 and up.) This is nothing new.
This problem appears resolved. Yes i686 has NPTL, i386 doesn't, life gets bumpy and weird when doing "rpm -Fvh /yadda/yadda/*"