Proposal(s) for handling libqt3-mt situation

[Modestas Vainius]

Hi,

2008 m. February 16 d., Saturday, Pierre Habouzit rašė:
>   Okay that's quite a few, so the "Conflict" option sucks. Here is
> another plan, tell me what you think, we put a debian specific hack in
> the glibc to reenable the extern inlines for _ONLY_ the packages that
> ask for it, for lenny, and remove it in lenny+1.
Ok, so it's actually a debate whether to readd missing symbols to affected 
libraries themselves or to libc6-dev. If Matthew is correct, all packages 
except trustedqsl are victims of libqt3-mt. By the way, I'm not sure if tsql 
is a problem (atoi is versioned?):

$ objdump -tT /usr/bin/tqsl | grep atoi
0000000000000000      DF *UND*  0000000000000015  GLIBC_2.2.5 atoi
$ objdump -tT /usr/bin/tqslcert | grep atoi
0000000000000000      DF *UND*  0000000000000015  GLIBC_2.2.5 atoi
$ objdump -Tt /usr/lib/libtqsllib.so.1.0.0 | grep atoi
0000000000000000      DF *UND*  0000000000000015  GLIBC_2.2.5 atoi

>   Qt _has_ to use it to build, though digikam and friends won't, so that
> they will _stop_ using the damn symbols. This way partial upgrades to
> lenny works, and in lenny+1 the symbols just disappear for good.
Sorry, but that's wrong. It's true that Qt gets those symbols at compile time, 
but any binaries linking against Qt references [fl]?stat64 from Qt at link 
time. Hence as long any application using [fl]?stat64 are linked against Qt3 
with [fl]?stat64 exported (and that has nothing to do with headers), it will 
depend on [fl]?stat64 being present.

If what you say was true, ktorrent 2.2.5.dfsg.1-1 should not depend on 
fstat64, because

1. ktorrent 2.2.5.dfsg.1-1 was uploaded on Wed, 06 Feb 2008 23:07:08 +0200, 
hence built against libc6-dev (>= 2.7) without extern inlines in sys/stat.h 
That's essentially the same as it would be building 
without -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK
2. qt-x11-free 3.3.7-9 was uploaded on Wed, 26 Sep 2007 21:42:24 +0200, hence 
built against libc6-dev (<< 2.7) with extern inlines in sys/stat.h present. 
That's essentially the same as it would be building 
with -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK
3. ktorrent 2.2.5.dfsg.1-1 was linked against qt-x11-free 3.3.7-9 (app, not 
using  -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK, was linked against lib, 
using -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK).

As you see, all conditions were met, but, unfortunately, ktorrent 
2.2.5.dfsg.1-1 still depends on exported fstat64

>   No Conflicts are needed, We only need a list of _library_ packages
> that have the stat (and other symbols) defined reuploaded with a
> -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK in the CFLAGS.
Do you want to add hack to lib6-dev just for Qt3?

>   Then a binNMU campaign of
> the broken _packages_ has to follow (digikam, k3b, ... ) so that they
> loose their wrong *UND* symbols for good.
Unless libqt3-mt loses them, binNMUs won't help.

P.S. However, we might want to delay libqt3-mt transition (by adding back 
[fl]?stat64 symbols one way or another and forgetting it) to lenny+1, because 
it's very likely that there will have been fewer applications using it by 
then.

-- 
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/20080216/c0e8cd86/attachment.pgp