Chris Burkhardt wrote:
Thanks, Christian, for filing the report and spending your Saturday making stack traces. I just upgraded to version 2.6.32.dfsg-3 of libxml2 from Unstable and it works (thanks Mike!). Hopefully it will be in Lenny and Etch soon.
There has just been a new DSA 1631-1 half an hour ago (heh, Steve Kemp forgot to bump the minor number I guess), which announces the availability of fixed packages in the security archive for Etch at least.
Thanks for your acknowledgment. I guess I wasn't in such a bad position knowing how to deal with the necessary tools like strace and gdb; judging from the other bug reports that turned up because of this bug, a few people were probably lost worse than me. What I didn't like was that the bug turned in when I wanted to work; I'm tempted to think "that's what you get for running testing", but actually running Etch wouldn't have saved me here.
I'm not a large-scale C developer nor a Debian developer, and while I understand what the reason of the segfaults was, I'm not sure what the right thing to improve upon that situation is. IIRC this is only the second time that I was confronted with a bug where changes in the layout of structs led to binary incompatibility (the other was a locally installed Perl module with mysql bindings, where libmysql changed). So it seems it's not a problem which is very widespread, but still I wonder what could be improved; I might be opening a little can of worms here, but I'll risk doing it. I'm seeing these ways:
(a) consider accessing library-internal types directly by using a header file of a library a bug if the library and the library consumer are to be packaged separately; since the way of packaging couldn't be safely foreseen by an application developper, this means, using such types from header files would *always* be a bad thing, and hence, a library exposing such information in it's public header files should be treated buggy itself.
or alternatively,(b) make packages of applications which are using such library-internal type information depend on an exact version of the library, so that when the library is being updated, the app needs to be recompiled; then I'd hope when the security team releases a package, the Debian infrastructure would complain automatically about which packages are loosing their dependency and hence need a recompile (with a new Depends package header).
For both cases, I guess it would be necessary to have a tool which checks for such unsafe linking usage, so that packagers can find out whether the package needs a strict version dependency for case (b), or whether the app or lib in question has a bug and needs fixing if policy (a) is to be taken.
Other than that, I'm seeing running all packages which depend on a package that is being updated for stable under a tool like valgrind which hopefully shows up all the buggy linkage at runtime as a third solution, but I guess that wouldn't be feasible in most cases because of the number of packages there are.
I'd be interested in what Debian developers think about these things. Thanks, Christian.