Proposal(s) for handling libqt3-mt situation

[Modestas Vainius]

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 [1].

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 [2] 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 <modestas at vainius.eu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080214/2220762d/attachment.pgp