Hi, As of writing, libqt3-mt ABI breakage caused serious 16 bugs (#464946 & friends) to be reported by our users. So I think it's high time we took some action today or tommorow to unbreak software affected. I'm concerned about Debian unstable users even though in theory they shouldn't be using unstable if they don't known how to downgrade packages. So this mail is all about how to deal with this situation having two main criteria in mind:
1) Solution should be technically correct. 2) It should have the least possible negative impact on unstable users. For starters, it seems that only 000000000070c5c8 w DF .text 0000000000000024 Base lstat64 000000000042ee4c w DF .text 0000000000000022 Base fstat64 00000000006075ea w DF .text 0000000000000024 Base stat64 are relevant for libqt3-mt case out of all symbols listed at . I see two major strategies how to deal with the breakage: 1) Ignore the fact that libqt3-mt ABI changed incompatibly because it affects a very low number of packages depending on libqt3-mt (maybe ~5-7 out of 396). In this case we could wait till qt3 3.3.8b-1 was build on all arches and binNMU those ~5-7 affected packages. Later if other packages are discovered, binNMU them immediately. This way of action is (imho): 1) technically incorrect (dropped symbols cannot be ignored in any case) 2) broken partial upgrades from etch are possible. 3) quality is traded for the fast/almost immediate solution with least hassle for developers (in the short term) and light load on buildds. In my opinion, this strategy is not acceptable for Debian (as I understand the Debian way of doing things) due to all points above. 2) The 2nd strategy would be to start libqt3-mt library transition. There are ~396 source packages, which binaries depend on libqt3-mt. However, this library transition would be a big inconvenience for developers and users (criteria 2) because it would take long time (397 packages to rebuild + delays while waiting until some are built on all arches). 1. Therefore, in my option, it's a must to "unbreak" libqt3-mt or affected packages before starting the transition. This could be done in two ways: a) add missing symbols back to libqt3-mt by uploading 3.3.8b-2 with patch like  applied. Then wait at least until 3.3.8b-2 is built on all arches having 3.3.8b-1 installed before starting the transition. In this case libqt3-mt ABI compatibility is fully restored, users can use previously broken known (to us) _and unknown_ packages w/o problems. Futhermore, temporary solving this problem in QT3 means less hassle for developers of affected packages. Finally effect of this solution should be nearly immediate. b) binNMU affected packages against libqt3-mt 3.3.8b-1 now. However, this would "unbreak" only those packages which were discovered until the start of the transition. Later discovered packages would have to wait until the end of the transition to be usable (or a user could take action (c) below). This solution means more communitication and a bit more delay. c) Don't do anything and tell users to downgrage libqt3-mt to 3.3.7-9 until transition ends. The problem is that we can't tell all users to do this and (a) (especially) or (b) seem much easier & more smooth ways. In case of (c), we could start transition immediately. 2. When #464946 & friends are temporary resolved one way or the other, transition could be started. This would involve renaming of libqt3-mt to e.g. libqt3-mt-1 or whatever and, once the latter has been built on all arches, binNMU'ing of all libqt3-mt reverse dependences. We could binNMU packages in groups doing the libraries and the most popular packages first (based on popcon rating) to avoid overloads on buildds. If either 1a or 1b has been done before transition, it should be nearly no hassle for our users, because aptitude (and apt-get too) should automatically hold libqt3-mt-1 and binNMU'ed packages until all (or most) packages installed on user's machine have been transitioned. Since all(1a)/most(1b) old versions of software will work with libqt3-mt, inconvenience should be minimal. By the way, transition should be started before upload of kde 3.5.9 to minimize load on buildds (hence all of KDE won't need to be binNMUed for transition, simply new upstream version will be uploaded for transition). Any suggestions? 1. http://article.gmane.org/gmane.linux.debian.devel.glibc/25981 2. http://alioth.debian.org/~modax-guest/qt/01_stat_extern_inline_hack.diff -- Modestas Vainius <[EMAIL PROTECTED]>
Description: This is a digitally signed message part.