[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

2.3.4-3 in experimental



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



Reply to: