I've duploaded 2.3.4-3 into experimental. It's also available at: http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental
This version should have the complete fix for the optimized package upgrade problem especially for i386 and sparc. The current glibc does _not_ handle multiple libc hwcap packages correctly during their upgrade. If ld.so in libc6 (2.3.4) is mixed with libc6.so in libc6-i686 (2.3.2.ds1-20), all binaries are suddenly stopped. It's caused by the internal change between ld.so and libc.so.6 during 2.3.3 development. To fix this problem, I put the change into 2.3.4-3 that uses /etc/ld.so.hwcappkgs to track the status of each hwcap packages (libc6 + libc6-i686 on i386, and libc6 + libc6-sparcv9 + libc6-sparcv9b on sparc). If hwcap package versions are not matched, /etc/ld.so.nohwcap is created until all package versions are installed. I tested two types of package transition as follows: * 2.3.2.ds1-20 (sarge) <=> 2.3.4-3 (etch) Sarge => etch transition. The following test scripts and special packages can test this situation. It adds libc6-i586 package in order to emulate sparc's two different optimized packages: http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/test-b/libc6{,-i686,-i586}*_i386.deb http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/test-b/log.b http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/transit.sh If you try to test it, put my libc6 packages into the proper place on chroot environment, then invoke as follows: # ./transit.sh b /232ds1-20-dir /234-3-dir * 2.3.2.ds1-100 <=> 2.3.4-3 This pattern emulates the future transition in etch (ex: 2.3.4 <=> 2.3.9x). 2.3.2.ds1-100 has the same ld.so.hwcappkgs script in 2.3.4-3, but libraries are stayed as 2.3.2.ds1-20. http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/test-a/libc6{,-i686,-i586}*_i386.deb http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/test-a/log.a If you want to test it, put my libc6 packages into the proper place, and edit transit.sh, then invoke as follows: # ./transit.sh a /232ds1-100-dir /234-3-dir I tested them on i386 - I couldn't test on sparc because Ultra SPARC III machine is required for checking libc6-sparcv9b. If you have Ultra SPARC III, I hope you test with the following packages (or dists/experimental ftp mirror): http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/libc6{,-sparcv9,-sparcv9b}*_sparc.deb For developers: The drawback of this method is: /etc/ld.so.nohwcap is left alone (== hwcap is disabled) during the following scenarios: 1. Downgrade from 2.3.4-3 to 2.3.2.ds1-*. In this case, ld.so.nohwcap keeps "downgrade-to-old-glibc" string. ld.so.nohwcap is not removed until 2.3.4-3 is installed. 2. Mismatch version detection within hwcap packages. Ex: if libc6 (2.3.4-3) is installed, but libc6-i686 2.3.4-3 is kept away, ld.so.nohwcap is not removed. When those versions are matched, ld.so.nohwcap is removed. The problem is even tls libraries are not loaded - so NPTL is disabled. But partial upgrade belongs to user's responsibility, it's out of scope. I thought this fix was also needed in 2.3.2.ds1-21, but finally I decided not to put this fix into 2.3.2.ds1-21 because of the drawback 1. If you have interested in the background of this mechanism theoretically, you possibly need to look at the transition diagram of these packages: * All version: http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/opt-crash.pdf * Separated graphics: 2.3.2.ds1-100 <=> 2.3.4-3 (i386 version): http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/opt-crash-i686.png 2.3.2.ds1-100 <=> 2.3.4-3 (i386/sparc version): http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/opt-crash-sparc.png 2.3.2.ds1-20 <=> 2.3.4-3 (i386/sparc version): http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/opt-crash-232ds1.png In this diagram, node represents each hwcap package combination. Edge represents an action of package installation or removal. Note that we don't need to care about some edge transitions because optimized packages has Pre-Depends: libc6 (ex: we cannot install libc6-i686 2.3.2.ds1-20 when libc6 2.3.4-3 is existed). Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]