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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
